Chrome incorrectly sending cookie attributes in HTTP request?

[José Miguel del Río]

Hi,
Our website is protected by a WAF system.
It is blocking a few users' requests because at the request Cookie header they are including the cookies' attributes (Secure, HttpOnly...), which violates RFC6265 (cookie attributes are meant to be specified by the server at the response Set-Cookie header, not sent back by the browser at the request Cookie header). E.g.:
Cookie: Lenguaje=es; path=/; domain=xxx; secure; httpOnly; ...
We wonder how the cookie attributes are making their way into the request Cookie header.

The User-Agent is supposedly a Chromium based one (Chrome, Edge), although you never know for sure.
If I'm looking at the right place (url_request_http_job.cc: SetCookieHeaderAndStart, canonical_cookie.cc: BuildCookieLine), I'd say the request's Cookie header line is built only with name=value pairs, not attributes.
There are other places in the code where the attributes are returned (e.g. BuildCookieAttributesLine), but I'd say it is not used to build HTTP requests.
In summary, is there any way Chrome could be building a request Cookie header with cookies' attributes in it?

Because another option we can think of is those users are (incorrectly) scripting HTTP requests, reusing the previously received cookies with their attributes.
Thanks for your feedback.

[Lily Chen]

You are correct about where the cookie line is constructed. The cookie serialization logic is here and hasn't changed in a while. I don't see any possible mechanism by which the attributes could make their way into the Cookie line.

Is it possible that the Set-Cookie headers are incorrectly using the attributes as separate cookie name=value pairs? Maybe it's an extension that modifies the Cookie header?

Without more info it's hard to say for sure. Is it possible to reach out to those users troubleshoot? If you can do that, it may be worth looking at the chrome://net-export log, which includes info about cookies that are included/excluded from requests. (But be aware that the log has different levels of detail and you may not want to share the more sensitive levels of info with anyone outside your organization.)

Another thing is that the example cookie line you sent, if that's actually verbatim, has suspicious capitalization: "httpOnly" is not a case that is normally used in the browser code (normally either "httponly" or "HttpOnly"), and it does not appear in any places that I would consider suspicious.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/1ce10107-0733-4fdb-b96b-03382a05951en%40chromium.org.

[Steven Bingler]

Hi,

Firstly, filing a bug at crbug.com will make it easier for us to help investigate this issue (if you want to continue investigating, that is).

I don't have any reason to suspect that Chrome is inadvertently inserting a cookie's attributes into the final cookie header sent on a request at the moment.

Like Lily suggested, it could occur if an incorrect separator is used or if there is an extension which modifies requests.

> Cookie: Lenguaje=es; path=/; domain=xxx; secure; httpOnly; 

Is this an exact piece of the request header you're seeing?

On Wednesday, May 29, 2024 at 10:25:38 AM UTC-4 Lily Chen wrote:

You are correct about where the cookie line is constructed. The cookie serialization logic is here and hasn't changed in a while. I don't see any possible mechanism by which the attributes could make their way into the Cookie line.

Is it possible that the Set-Cookie headers are incorrectly using the attributes as separate cookie name=value pairs? Maybe it's an extension that modifies the Cookie header?

Without more info it's hard to say for sure. Is it possible to reach out to those users troubleshoot? If you can do that, it may be worth looking at the chrome://net-export log, which includes info about cookies that are included/excluded from requests. (But be aware that the log has different levels of detail and you may not want to share the more sensitive levels of info with anyone outside your organization.)

Another thing is that the example cookie line you sent, if that's actually verbatim, has suspicious capitalization: "httpOnly" is not a case that is normally used in the browser code (normally either "httponly" or "HttpOnly"), and it does not appear in any places that I would consider suspicious.

On Wed, May 29, 2024 at 9:55 AM José Miguel del Río <josemigueldelriomartinez@gmail.com> wrote:

Hi,
Our website is protected by a WAF system.
It is blocking a few users' requests because at the request Cookie header they are including the cookies' attributes (Secure, HttpOnly...), which violates RFC6265 (cookie attributes are meant to be specified by the server at the response Set-Cookie header, not sent back by the browser at the request Cookie header). E.g.:
Cookie: Lenguaje=es; path=/; domain=xxx; secure; httpOnly; ...
We wonder how the cookie attributes are making their way into the request Cookie header.

The User-Agent is supposedly a Chromium based one (Chrome, Edge), although you never know for sure.
If I'm looking at the right place (url_request_http_job.cc: SetCookieHeaderAndStart, canonical_cookie.cc: BuildCookieLine), I'd say the request's Cookie header line is built only with name=value pairs, not attributes.
There are other places in the code where the attributes are returned (e.g. BuildCookieAttributesLine), but I'd say it is not used to build HTTP requests.
In summary, is there any way Chrome could be building a request Cookie header with cookies' attributes in it?

Because another option we can think of is those users are (incorrectly) scripting HTTP requests, reusing the previously received cookies with their attributes.
Thanks for your feedback.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[José Miguel del Río]

Thanks, Lily and Steven, for your answers.

BTW, not sure if I'm doing it right (I'm new to Google Groups): for some reason, Steven's update doesn't show at the group discussion web interface, only I got it by email, so I wonder if replying to this email is the right way to go or I'd rather reply through the web interface. although the latest update is missing for the time being.

Regarding the Set-Cookie by our web server, this is the verbatim header:

Set-Cookie: Lenguaje=es; path=/; secure; HttpOnly

and yes, this is the verbatim request Cookie header:

Cookie: ...; Lenguaje=es; path=/; domain=www1.sedecatastro.gob.es; secure; httpOnly; sameSite=Lax; ...

so I'd rule out incorrect setting by the server, and regarding the httpOnly case (good point) , elaborating on Lily's suggestion, seaching for

\"httpOnly

literals, I'd find it only in this place, which I guess also rules out normal use of the browser by a standard user.

So for the time being we have told the user to check their use of the Cookie header (because we suspect they might be incorrectly automating their requests, maybe using third-party code as you guess).

And should they insist on their normal use of the browser, I'll ask them to provide a net-export log and, if confirmed, possibly file a crbug.

Thanks a lot.

El mié, 29 may 2024 a las 20:07, Steven Bingler (<bin...@chromium.org>) escribió:

Hi,

Firstly, filing a bug at crbug.com will make it easier for us to help investigate this issue (if you want to continue investigating, that is).

I don't have any reason to suspect that Chrome is inadvertently inserting a cookie's attributes into the final cookie header sent on a request at the moment.

Like Lily suggested, it could occur if an incorrect separator is used or if there is an extension which modifies requests.

> Cookie: Lenguaje=es; path=/; domain=xxx; secure; httpOnly; 

Is this an exact piece of the request header you're seeing?

On Wednesday, May 29, 2024 at 10:25:38 AM UTC-4 Lily Chen wrote:

You are correct about where the cookie line is constructed. The cookie serialization logic is here and hasn't changed in a while. I don't see any possible mechanism by which the attributes could make their way into the Cookie line.

Is it possible that the Set-Cookie headers are incorrectly using the attributes as separate cookie name=value pairs? Maybe it's an extension that modifies the Cookie header?

Without more info it's hard to say for sure. Is it possible to reach out to those users troubleshoot? If you can do that, it may be worth looking at the chrome://net-export log, which includes info about cookies that are included/excluded from requests. (But be aware that the log has different levels of detail and you may not want to share the more sensitive levels of info with anyone outside your organization.)

Another thing is that the example cookie line you sent, if that's actually verbatim, has suspicious capitalization: "httpOnly" is not a case that is normally used in the browser code (normally either "httponly" or "HttpOnly"), and it does not appear in any places that I would consider suspicious.

On Wed, May 29, 2024 at 9:55 AM José Miguel del Río <josemiguelde...@gmail.com> wrote:

Hi,
Our website is protected by a WAF system.
It is blocking a few users' requests because at the request Cookie header they are including the cookies' attributes (Secure, HttpOnly...), which violates RFC6265 (cookie attributes are meant to be specified by the server at the response Set-Cookie header, not sent back by the browser at the request Cookie header). E.g.:
Cookie: Lenguaje=es; path=/; domain=xxx; secure; httpOnly; ...
We wonder how the cookie attributes are making their way into the request Cookie header.

The User-Agent is supposedly a Chromium based one (Chrome, Edge), although you never know for sure.
If I'm looking at the right place (url_request_http_job.cc: SetCookieHeaderAndStart, canonical_cookie.cc: BuildCookieLine), I'd say the request's Cookie header line is built only with name=value pairs, not attributes.
There are other places in the code where the attributes are returned (e.g. BuildCookieAttributesLine), but I'd say it is not used to build HTTP requests.
In summary, is there any way Chrome could be building a request Cookie header with cookies' attributes in it?

Because another option we can think of is those users are (incorrectly) scripting HTTP requests, reusing the previously received cookies with their attributes.
Thanks for your feedback.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.