Intent to Implement and Ship: Limit `Referer` header's length to 4k.

[Mike West]

Contact emails mk...@chromium.org Explainer https://github.com/whatwg/fetch/issues/903 Design docs/spec Specification: https://github.com/w3c/webappsec-referrer-policy/pull/122 https://github.com/whatwg/fetch/issues/903 TAG review This is a very minor change, with two other vendors signing off. Summary If the `Referer` header's value would exceed 4k, it will be stripped down to an origin. Motivation As noted in https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels#cache-and-error-events, servers will often behave in unexpected ways when presented with an overly-long `Referer` header. This is unfortunate, as `Referer` is one header whose length attackers generally retain control over when generating `no-cors` requests. Perhaps we can cap it to something reasonable? Risks

Interoperability and Compatibility There's some risk to altering the `referer` header, as sites do use it in various ways. This risk seems manageable. Based on Chrome's telemetry from Canary/Dev, the header is rarely long enough to be affected: capping the length at 4k would affect 1 in 10,000 requests. The percentiles look like: * 25.00% 27.53 * 50.00% 44.76 * 75.00% 79.71 * 95.00% 263.3 * 99.00% 986.5 * 99.50% 1232 * 99.90% 1956 * 99.99% 4162 Still, there's some risk that dropping path information could have an adverse affect on some site, somewhere. We ran an experiment in Canary/Dev that stripped headers down to an origin at 4k and 2k, but didn't find any statistically relevant difference in error rates for either top-level navigations or subresource requests. Mozilla and Edge folks both are willing follow us to 4k if we land it successfully (in fact, both suggested lower limits). Firefox: Public support (https://github.com/whatwg/fetch/issues/903) Edge: No public signals (https://github.com/whatwg/fetch/issues/903) Safari: No public signals Web developers: No signals Ergonomics None. Activation None. Security We considered simply cutting the `Referer` header's value at the limit, rather than stripping it down to an origin. This would potentially leave the URL in a strange state by breaking %-encoding, or removing security-critical GET parameters. An origin is significantly more likely to be safe.

Debuggability The header will be represented correctly in devtools, just as it is today. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? It will be. The existing `referrer-policy` tests are extended in https://chromium-review.googlesource.com/c/chromium/src/+/1646784 (https://github.com/web-platform-tests/wpt/pull/17204) to cover the length limitation. Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=959757 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5648956820291584

-mike

[Yoav Weiss]

4K Referer headers ought to be enough for anybody :D

LGTM1

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DcA7Xn%3DMYi_g-Q%3D2_LpFkL3erPEwQAnauRWuKfU7dcwMw%40mail.gmail.com.

[Jochen Eisinger]

lgtm2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEghep0DD3FqUgUFAnuJAtHdLPttv78dXNZBReJUzFKfxg%40mail.gmail.com.

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuif0hzKRc7z%3D6uVSqM8p%3DmH_%3DYMDAEJqb186AQmd_9iq3A%40mail.gmail.com.

[Eric Lawrence]

lgtm: I think Edge is meant to say Public support. ;-) 

[ati...@outlook.com]

Thank you for this security feature update. However, this is breaking some features for our long URLs. How can I disable this feature temporarily from command line so it does not limit?

[Mike West]

For the moment, you can append `--disable-features=CapRefererHeaderLength` to your command line. Note, though, that I intend to remove this in Chrome ~80, which will hit stable early next year. I hope you can find a workaround in the next few months! :)

-mike

--

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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/881b2bcb-3401-475f-9234-9f770043bced%40chromium.org.