Listing headers safe only for certain values is a bad idea

[sicking]

I just noticed that the headers DPR, Downlink, Save-Data, Viewport-Width and Width have been listed as "safe" headers only for certain values.

I think this is a bad idea. Having only certain values be considered safe introduces complexity in a security API. This increases the risk that something will go wrong and that security bugs will ensue.

Consider for example https://bugs.chromium.org/p/chromium/issues/detail?id=490015 which is a recent example of a case where such complexity has lead to a security bug which has remained in Chrome for over a year and which is unclear if it will ever get fixed.

Another reason to not consider these headers safe only for certain values is that the set of values is bound to change over time. As the specification for those headers evolve over time, so will the the set of values that will parse successfully.

Are we expecting website developers to constantly monitor these specifications and adjust their server side code as it can get exposed to new request headers?

[mnot]

cc @igrigorik

[igrigorik]

I just noticed that the headers DPR, Downlink, Save-Data, Viewport-Width and Width have been listed as "safe" headers only for certain values.

I think this is a bad idea. Having only certain values be considered safe introduces complexity in a security API. This increases the risk that something will go wrong and that security bugs will ensue.

This statement is not obvious to me. IETF specs define the grammar for particular fields, it seems reasonable for user agents to validate provided values against said definitions and reject values that do not conform to the spec -- this process, by itself, does not increase risk of security bugs. However, it's probably also true that this mechanism should not be considered as a "security mechanism" either:

• Many field definitions allow effectively arbitrary data to be sent
• Some fields may be more strict but these same fields may change in the future to allow other values

Which is to say, even if the user agent enforces some checks, the server must still validate all input fields and cannot and should not count on the user agent to "protect it". So yes, website developers should monitor and enforce their own rules with regards to what values are allowed by specification or their particular implementation.

---

@sicking what is your alternative proposal? Are you suggesting that we should skip UA validation entirely and defer to the server?

[sicking]

CORS is entirely a "security mechanism". It defines which headers (and, sadly header values) can be sent on incoming requests from 3rd parties.

If you want servers to expect arbitrary values for these headers on requests from 3rd parties, and want servers to validate there are no values that have harmful side effects, then the appropriate thing is to whitelist these headers for any value.

That way web developers have to expect incoming requests with any value from a 3rd party attacker since such an attacker can use fetch() or XHR to submit such requests.

Note that because the CORS spec says that the Content-Type header currently only can contain text/plain, application/x-www-form-urlencoded or multipart/form-data we know of authors which has written server side code which relies on that these are the only content types that they will receive from 3rd parties.

The reason we know was because we had bugs somewhere in our sendBeacon implementation (i think) which enabled sending other content-types and got bugs filed against us specifically referencing the requirement on the Content-Type header in the spec. Sadly I don't remember the details, nor am I able to find the bug.

[igrigorik]

web developers have to expect incoming requests with any value from a 3rd party attacker since such an attacker can use fetch() or XHR to submit such requests

I guess you could (should?) extend that same statement to any request (3rd party or not), since any script included on the page (regardless of origin), or introduced due to XSS vector/etc, could carry a value with some harmful side effects.

@annevk @mnot any thoughts on this one?

[annevk]

I know from https://lists.w3.org/Archives/Public/public-webappsec/2016May/0034.html that there's at least some security folks wanting to restrict the existing CORS-safelisted request-headers (e.g., Accept) to some set of limited values too.

The reason we restricted the values for these new headers is that Chrome was already violating the same-origin policy for them, with <img> et al, but only with valid values. So letting fetch() do the same for valid values seemed reasonable and this passed security review.

[sicking]

I'm certainly opposed to implementing this in Gecko. Who did the security review on the Mozilla side?

[sicking]

FWIW, I'm similarly opposed to adding restrictions to Accept

[igrigorik]

/cc @johnwilander @mikewest for comments on the webappsec discussion... :)

[annevk]

@dveditz thoughts?

[johnwilander]

Sorry for joining late. We are moving the #382 discussion here.

@sicking I read your position as "Browser restrictions on CORS header values 1) will make servers rely on them and thus result in poor server input validation, and 2) will result in more security bugs filed against browsers." True?

Servers that depend on browser enforced header values might as well result in better server-side input validation, right? For the Content-Type header, the current restriction might as well result in the server comparing with an enum and accepting nothing else.

[annevk]

I'm not sure how actively involved @sicking still is. So I guess we need input from someone else from Mozilla, e.g., @mcmanus or @smaug----. @tyoshino any thoughts from Google's end on adding more restrictions (to Accept, Accept-Language, etc.)?

[sicking]

I can't speak for mozilla any longer, so definitely advice getting input from others.

That said, I don't understand @johnwilander's comment. Why would the fact that browsers enforce preflight for, for example "application/xml", mean that server authors are more likely to test that the content-type really is one of the whitelisted ones?

[tyoshino]

There's no lecture about the original issue for which the preflight mechanism was introduced around the Access-Control-Allow-Headers definition in the Fetch Standard, yet, IIUC. Even if there is such educating texts, basically the CORS preflight has impact only for developers with much curiosity and carefulness so that they think more about the purpose of the mechanism and what they should do, I think. I'm not sure if this kind of "heads up" has been so effective.

If we stand the position that this has been not effective, we shouldn't complicate it anymore as it's useless.

If we stand the position that this has been effective, we could say either:

1. let's address new attack vectors at web browser
2. developers have been well educated for 8 years. now they're responsible for fixing issues by themselves

(1) will results in banning almost all all kind of cross-site XHR/Fetch and require explitict permission by preflight for everything in the future while sacrificing the cost of extra RTT.

My gut feeling is that we should take the position (2) to share the cost for fighting with attacks between browser vendors and service developers, and make the world with less latency.