- From: Anne van Kesteren <notifications@github.com>
- Date: Wed, 08 May 2019 06:34:35 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 8 May 2019 13:34:59 UTC
As it's attacker-controlled it can be used for cache-eviction or determining cookie size. To quote @mikewest in https://bugs.chromium.org/p/chromium/issues/detail?id=959757 (it's worth reading this for some more relevant discussion): > 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? This would be conceptually similar to the cap in https://fetch.spec.whatwg.org/#cors-safelisted-request-header for CORS requests... cc @whatwg/security -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/903
Received on Wednesday, 8 May 2019 13:34:59 UTC