CORS-safelisted request headers should be restricted according to RFC 7231

[johnwilander]

Fetch only restricts Content-Type request values beyond field-content token production: https://fetch.spec.whatwg.org/#cors-safelisted-request-header

This means simple CORS requests can send unexpected characters in Accept, Accept-Language, and Content-Language header values. As an example, header value "() { :;};" could exploit the infamous Shellshock server vulnerability from 2014 (http://www.cvedetails.com/cve/cve-2014-6271).

RFC 7231 does not allow "() { :;};" as a value for these headers from what I can tell:
Accept https://tools.ietf.org/html/rfc7231#section-5.3.2
Accept-Language https://tools.ietf.org/html/rfc7231#section-5.3.5
Content-Language https://tools.ietf.org/html/rfc7231#section-3.1.3.2

So far browsers have not restricted these headers and so server backends have to do the validation. I suggest we close this payload delivery mechanism in the Fetch spec.

This was briefly discussed at the W3C WebAppSec meeting May 17, 2016: https://www.w3.org/2011/webappsec/minutes/2016-05-17-webappsec-minutes.html#item08

[annevk]

Did you see #313? Also, wouldn't this potentially break a ton of deployed content?

[johnwilander]

I did not see #313. My GitHub account was set up with an old email address which is why I didn't react on the ping in June. Sorry about that.

As for risk of breakage, yes, things will break. That's why we want to do this in a coordinated way.

From what I hear the decision to field-content token production for these headers was never really specified.

Should we have the security discussion here or in #313?

[annevk]

The other issue is probably better since it has more folks copied. (And yeah, the definition of a header value needs work: #332.)