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. 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). 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 Web developers: N/A - these changes are relatively small and are in alignment with the RFC, other browsers, and/or existing behavior 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/CAEa0%2BkWpfzZNoZ0pvrG-rR-t4csN1CLVA56SJQj2ksEcG-81Xw%40mail.gmail.com.
