[CSP] specify handling of malformed content-security-policy HTTP header

[mikewest]

From @shekyan on October 2, 2015 23:31

Section 3.1 should be explicit how user-agent should behave in the context of malformed content-security-policy header. For example, unknown directive, non-ASCII characters, multiple 'none' keywords in source-expression do not match the 'policy-token' grammar.

We suggest treating these headers as either default-src 'none' or default-src 'self'

Copied from original issue: w3c/webappsec#495

[mikewest]

From @metromoxie on October 3, 2015 0:31

There are more nuanced alternatives. For example, if a source expression in a source list has a malformed character, we can just ignore the single source expression. This, in fact, is how I read the current spec (since it simply doesn't add it to the list of sources if it can't be parsed), but it would be nice if it was explicit.

[mikewest]

From @michaelficarra on October 3, 2015 21:24

@metromoxie Being permissive like that can lead to unintentional vulnerabilities at worst and strange inconsistencies at best, unless the specification is very explicit about the details of error recovery. As-is, the specification does not make much sense, parsing source lists in one way in the source-list grammar and another way in section 4.2.1. For example, (and this is mostly targeted at @shekyan), 4.2.1 separates source expressions on U+0020 (space), U+0009 (tab), U+000A (line feed), U+000C (form feed), and U+000D (carriage return), and the source-list grammar separates source expression on WSP, which is only U+0020 (space) and U+0009 (tab).

The easiest way to safely handle this is to fall back to some restrictive default for malformed policies. Care should be taken, though, to allow for future directives and possibly even extensions to the grammar.

[mikewest]

From @metromoxie on October 5, 2015 18:33

@michaelficarra Sure, but we should explore all the options, especially when one of them is how it appears to be currently defined. And if we change it to be more closed, we risk breaking sites that are currently compatible with the spec, which might be a nasty surprise.

[foolip]

It looks like this issue, the lack of defined error handling, has led to different behavior between browsers and a site compat issue for Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1629699. Thanks @bakkot for pointing me here in https://github.com/w3c/webappsec-csp/issues/434#issuecomment-628066542.

I see that https://github.com/w3c/webappsec-csp/pull/363 to fix this has been open for a long time.

@mikewest is the desired behavior clear at this point and it's "just" a matter of writing it down, or is there more work to do still?