Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mikewest opened this issue Oct 7, 2015 · 4 comments · May be fixed by #363
Open

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

mikewest opened this issue Oct 7, 2015 · 4 comments · May be fixed by #363
Milestone

Comments

@mikewest
Copy link
Member

mikewest commented Oct 7, 2015

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
Copy link
Member Author

mikewest commented Oct 7, 2015

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
Copy link
Member Author

mikewest commented Oct 7, 2015

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
Copy link
Member Author

mikewest commented Oct 7, 2015

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
Copy link
Member

foolip commented May 18, 2020

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 #434 (comment).

I see that #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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants