Here is the percentage for the metric mentioned in my last email: over a 7 day period, 0.00004% of cookies seen in the stable version of Chrome had truncated names and/or values.
Ultimately our plan is to ship this feature behind a kill switch that we could flip if major issues are reported. With that in mind, and given the low number of truncated cookie names/values observed via our existing metrics, would it make sense to implement and collect the new metrics in parallel with rolling out the changes described in this I2P&S? Or do you think taking the more cautious approach and implementing/collecting the new metrics before landing this change is a better way forward (despite taking more time)? -Andrew On Fri, Aug 27, 2021 at 1:45 PM Andrew Williams <awil...@chromium.org> wrote: > Thanks for the feedback/questions Yoav and Daniel. > > We have some metrics > <https://source.chromium.org/chromium/chromium/src/+/700dc7fe1578ab5e0e50a6304f2a1960005b8f8b:tools/metrics/histograms/metadata/cookie/histograms.xml;l=56;bpv=1;bpt=0> > on Chrome's existing behavior to truncate cookie lines containing \x00, > \x0d, and \x0a (specifically, in cases where the truncation affects the > cookie name or the cookie value). The percentage of cookies with truncated > names or values is quite low, although I'm still waiting on approval to > release the exact percentage. We don't have any metrics for cases where > truncation affected cookie attribute parsing (for example, the malicious > case this intent aims to address) or where truncation was harmless (for > example, a newline as the last character in the cookie line), though. > Especially for the latter case, it does seem plausible that certain sites > could be constructing cookie lines in such a way that control characters > slip in unnoticed. We will add new metrics to cover these cases so that we > can better predict the level of breakage that these changes may have. > > -Andrew > > On Thu, Aug 26, 2021 at 2:22 PM Daniel Bratell <bratel...@gmail.com> > wrote: > >> 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 emails awil...@chromium.org, miketa...@chromium.org Explainer >>> >>> 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 >> <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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/44805dc7-edd8-218d-dcbe-9c589509b633%40gmail.com?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/CAEa0%2BkVXcVihrkHbp5s9SH2y1BsYVgyMBqPTcZ1fy7vAz8DUfw%40mail.gmail.com.
