W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [CSP] <meta> clarifications

From: Mike West <mkwst@google.com>
Date: Tue, 20 Jan 2015 12:08:08 +0100
Message-ID: <CAKXHy=fUMJcVFh=7C_1KKDjnqzRBAnF9gFJK_cWLDbqX23pryA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Jan 19, 2015 at 6:38 PM, Brian Smith <brian@briansmith.org> wrote:

> From what I remember when I started this thread months ago, there
> was/is some significant difference in how browsers enforce multiple
> policies. IIRC, Devdatta noticed it too, and he might have an example
> more readily available.

It's been a while (sorry!), so I hope that's no longer the case. :)

I think what is needed is a normative algorithm for constructing a set
> of policies from the HTTP headers and <meta> elements (including
> handling cases where the content of a <meta> element contains "," to
> indicate multiple policies), and a normative algorithm for enforcing
> all the policies in the document.

I believe this is already a requirement in the document. In section 3.1, we
say "Upon receiving an HTTP response containing at least one
Content-Security-Policy header field, the user agent MUST enforce each of
the policies contained in each such header field." In section 3.2, we say
"Upon receiving an HTTP response containing at least one
Content-Security-Policy-Report-Only header field, the user agent MUST
monitor each of the policies contained in each such header field." We
explain each of those terms in

What I'm hearing from you is that that requirement isn't clearly explained.
I'd hoped that the non-normative section we're discussing would have taken
care of the explanations. Perhaps we're relying too much on implicit
understanding of the comma mechanics of rfc7230? Is that the core of the
area in which you'd appreciate clarification?

> Note that the wording of the <meta>
> section implies that a meta element can only contain a single policy
> and that there is only a single <meta> element containing a CSP, which
> I think is not intended.

should make this more explicit.

A browser than warned about the use of <meta> to deliver CSP in an
> every HTTPS- or HTTP- delivered document would conform to the
> requirement.

And I think we'd both claim that it would also be not particularly useful.

> A browser that skipped the warning when the <meta> CSP
> elements is preceded only by <!DOCTYPE html>, <html>, <head>,
> <title>...</title>, and <meta charset> (and no Link: headers) would be
> better. The important thing is to help web developers avoid
> unintentionally misusing <meta> CSP in a way that isn't effective.

Given that browsers do smart things like prescanning the document to kick
off requests during parsing and layout, I'm not even sure the second
example would do what you expect all the time.

> > Regardless, I really need to spend some time upstreaming tests to
> > WebPlatformTests, which is totally on my todo list.
> I think adding the test cases to the conformance test suite would be
> good to ensure that browsers do this consistently.

Totally agree. This is down to my laziness, nothing more.

> Note that the current draft says that modiifications to the content of
> an existing <meta>-delivered policy will ignored. Given what you say
> above, I think it is worth reconsidering whether that makes sense. In
> particular, if adding <meta> elements results in additional
> restrictions, and removing <meta> elements results in fewer
> restrictions, why shouldn't modifying an existing <meta> element be
> equivalent to removing it and adding a new one with the new content?

Removing a <meta> element does not result in fewer restrictions. The <meta>
element delivers a policy, which is either "enforced" or "monitored" as a
result of parsing the element. Removing the element doesn't change the
effective set of policies applied to a document, nor should it.

Or maybe it should? That might have interesting properties. But it's not
something we should explore in CSP2. Filed
https://github.com/w3c/webappsec/issues/153 to think about it later. :)


Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 20 January 2015 11:08:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC