CSP2: Default value of default-src is incorrect

[april]

Here is what the current specification says:

Let the default sources be the result of parsing the default-src directive’s value as a source list if a default-src directive is explicitly specified, and otherwise the U+002A ASTERISK character (*).

Which is incorrect, as it reads that these two statements are equivalent:

Content-Security-Policy: default-src *; upgrade-insecure-requests
Content-Security-Policy: upgrade-insecure-requests

The statement should probably read something like:

Let the default sources be the result of parsing the default-src directive’s value as a source list if a default-src directive is explicitly specified, and otherwise the list of all possible sources.

(cc: @hillbrad, as @mikewest told me to)

[april]

Note that this appears to be fixed in CSP3, as near as I can tell.

[mikewest]

Yup. This is broken in CSP2. Although I think that we decided in some other bug that it didn't matter because CSP2 was so loosely specified that the * was never "enforced". Let me see if I can track that down.

[mikewest]

w3c/webappsec-csp#9 (comment) is what I was thinking of. @hillbrad, @wseltzer, @dveditz: Is it worth revising CSP2 at this point? WDYT?

[april]

Well, I'm fine with this being loosely specified as well, just as long as it's clear that the two hand-wavingly vague definitions are distinct.

The browsers treat them very differently, and so this line was very confusing to me both when it came to writing documentation about CSP as well as when writing a CSP analyzer.

[mikewest]

The browsers treat them very differently

Do you mean that browsers treat a missing default-src (like Content-Security-Policy: script-src 'self') differently? Or that * means something very different from "nothing"?

[april]

The latter. Not having a default-src is very different than default-src *, but the CSP2 spec implies that they are the same.

[hillbrad]

So, by "fixed in CSP3" does that mean we expect different behavior from the
same policy strings? Or do you mean the existing behavior is more clearly
explained?

I think we can maybe punt on updating CSP2 if we verify by the test suite
that our implementations behave similarly. If they have diverged due to
unclear language we need to fix it.

On Mon, Apr 18, 2016 at 2:22 PM April King [email protected] wrote:

The latter. Not having a default-src is very different than default-src *,
but the CSP2 spec implies that they are the same.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#514 (comment)

[april]

The behavior hasn't changed in CSP3, it's just that the CSP3 accurately describes the implemented behavior where as CSP2 does not.

[hillbrad]

Test shows that Chrome, Firefox and Safari Tech Preview are all compliant, so we can try to make this correction as a non-conformance affecting edit. (I'll manage that, @mikewest )

[mikewest]

You are the best, @hillbrad. Thank you!

[mikewest]

Fixed this in the editor's draft, using @marumari's suggestion. Brad, perhaps you could sneakily apply w3c/webappsec-csp@bc9577d to the CR? (Let's leave this bug open until that's addressed)