Even if browsers are currently slightly incompatible, it seems this
change will short term make them more incompatible. As Yoav said, it
would be good to have an idea about how common this is, i.e. how often
will cookies that are today truncated instead be rejected?
/Daniel
On 2021-08-25 16:18, Yoav Weiss wrote:
Hey Andrew! Thanks for working on this, this seems like a significant
compatibility gap (with security implications) that would be great to
close.
On Tuesday, August 24, 2021 at 3:45:50 PM UTC+2 Andrew Williams wrote:
Contact emailsawil...@chromium.org
<mailto:awil...@chromium.org>, miketa...@chromium.org
<mailto:miketa...@chromium.org>
Explainer
https://github.com/httpwg/http-extensions/issues/1531
<https://github.com/httpwg/http-extensions/issues/1531>
https://github.com/httpwg/http-extensions/pull/1589
<https://github.com/httpwg/http-extensions/pull/1589>
Specification
https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md
<https://github.com/httpwg/http-extensions/blob/main/draft-ietf-httpbis-rfc6265bis.md>
Summary
Updates how control characters in cookie data are handled.
Specifically, the tab character is now permitted, but all other
control characters cause the entire cookie to be rejected
(previously the \x00, \x0D, and \x0A characters in a cookie line
caused it to be truncated instead of rejected entirely, which
could have enabled malicious behavior in certain circumstances).
This behavior is also in line with the latest drafts of RFC6265bis.
Blink component
Internals>Network>Cookies
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies>
Motivation
In the case where attacker controlled data is used to set a new
cookie, having certain control characters truncate the cookie line
could result in security-related cookie attributes being ignored.
This behavior may also lead to cookie data corruption when control
characters are introduced, which may cause unpredictable behavior
on the application side (more so than cookies not being set, which
is a case that applications should already handle). Having control
characters result in the whole cookie being rejected helps
mitigate these concerns and aligns Chrome with RFC6265bis. For
the tab character, although it falls in the control character
range (\x00 - \x1F, \x7F), it’s a printable character and allowed
by other browsers. Treating it the same way that the space
character is treated makes sense intuitively, eliminates a
potential fingerprinting vector, and aligns Chrome with RFC6265bis.
In the past, moving to a stricter models that forbade certain
characters resulted in at least some breakage of non-malicious
content. I doubt this one would be significantly different.
Do you have a sense of the resulting breakage? If not, I think it'd
make sense to add metrics to our cookie parsing algorithm and see what
that breakage would look like.
Initial public proposal
TAG review
N/A
<https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/uBxq9uCpKx0/m/A5LI0NbyAAAJ>:
this change is already specified in RFC 6265bis and is a
relatively minor change to what's already implemented in Chrome
(to improve spec compliance).
I agree that this change is in lower layers than those the TAG usually
deals with.
TAG review statusNot applicable
Risks
N/A
Interoperability and Compatibility
WebKit / Safari:
- All control characters except the tab character cause the
cookie to be rejected if present in the name and cause the rest of
the cookie line to be truncated if present in the value
Gecko / Firefox:
- 0x00 in the cookie value causes the rest of the value to be
truncated (but subsequent attributes are preserved)
- 0x00 in the cookie name causes the rest of the name and the
value to be truncated (but subsequent attributes are preserved)
- 0x0d and 0x0a cause the entire cookie line to be truncated
(attributes ignored)
- 0x01 through 0x09 (the tab character), 0x0b through 0x0c, and
0x0e through 0x1f cause the cookie to be rejected if they are
present in the name, but are allowed in the cookie value
- 0x7f is allowed in the cookie name and cookie value
The following issues exist reporting these differences:
*
Firefox -
https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1
<https://bugzilla.mozilla.org/show_bug.cgi?id=1702031#c1>
*
WebKit - https://bugs.webkit.org/show_bug.cgi?id=229088
<https://bugs.webkit.org/show_bug.cgi?id=229088>
Allowing tab characters in cookie names aligns Chrome with Safari
but not Firefox, and allowing tabs in the cookie value aligns
Chrome with both.
Regarding control characters (not including tab), what will change
in Chrome is the handling of 0x00, 0x0d, and 0x0a characters.
Today, Chrome truncates cookie lines when these characters are
encountered, and this intent proposes having these characters
result in cookie rejection instead. Rejecting cookie names
containing these characters aligns Chrome with Safari but not
Firefox, but rejecting cookie values containing these characters
is inconsistent with existing Safari or Firefox behavior.
However, these changes unify Chrome’s control character handling
behavior, better align Chrome with RFC6265bis, and also help
prevent a class of cookie attribute removal attacks (when
malicious input is used to build a cookie line under certain
conditions).
Gecko: N/A - these changes seem too small to justify this
effortWebKit: N/A - these changes seem too small to justify this
effort
I somewhat agree that asking for a position here would be an overkill,
but would love to get a signal from both Mozilla and Safari on their
intents to align with the RFC. (the former seems more likely than the
latter, as this seems like a CFNetwork issue)
At the same time, the issues seem sufficient for that purpose,
assuming folks there respond.
Web developers: N/A - these changes are relatively small and are
in alignment with the RFC, other browsers, and/or existing behavior
Yeah, developers are unlikely to be happy about this from a breakage
perspective, even if it'd reduce compat issues. The main thing we can
do about that is ensure breakage is minimal before shipping.
Debuggability
DevTools debugging support will be implemented along with this
change. Rejected response cookies are already shown in DevTools in
the Network panel, with a status explaining why they were
rejected. Another status will be added to annotate cookies
rejected due to control characters.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
In Progress -
https://chromium-review.googlesource.com/c/chromium/src/+/3084521
<https://chromium-review.googlesource.com/c/chromium/src/+/3084521>
Flag name
UpdatedCookieControlCharacterChecks
Requires code in //chrome?
False
Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1233602
<https://bugs.chromium.org/p/chromium/issues/detail?id=1233602>
Estimated milestones
M96
Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5709264560586752
<https://www.chromestatus.com/feature/5709264560586752>
Requesting approval to ship?
Yes
This intent message was generated by Chrome Platform Status
<https://www.chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2de8b96-8878-47fe-99e2-5497b96c9adcn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e2de8b96-8878-47fe-99e2-5497b96c9adcn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com.
