- From: Mike West <mkwst@google.com>
- Date: Tue, 20 Jan 2015 12:08:08 +0100
- To: Brian Smith <brian@briansmith.org>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=fUMJcVFh=7C_1KKDjnqzRBAnF9gFJK_cWLDbqX23pryA@mail.gmail.com>
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 https://w3c.github.io/webappsec/specs/content-security-policy/#processing-model . 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. > https://github.com/w3c/webappsec/commit/35aa6f7674c22c3178f6d67d98c0602ff509f65e 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 -- 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 Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Tuesday, 20 January 2015 11:08:56 UTC