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 emails > awil...@chromium.org, miketaylr@chromium.orgExplainer > > https://github.com/httpwg/http-extensions/issues/1531 > > https://github.com/httpwg/http-extensions/pull/1589 > > Specification > > > 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 status > Not 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 > - > > WebKit - 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 effort > WebKit: 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 > Flag name > > UpdatedCookieControlCharacterChecks > Requires code in //chrome? > > False > Tracking bug > > 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 > > 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. 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.
