Re: [CSP] <meta> clarifications

On Mon, Jan 19, 2015 at 7:35 AM, Brian Smith <brian@briansmith.org> wrote:

> Mike West <mkwst@google.com> wrote:
> > Brian Smith <brian@briansmith.org> wrote:
> > I've (belatedly) addressed these points in
> >
> https://github.com/w3c/webappsec/commit/3e856006a34d9f75d28d696c510f055084567c29
> .
>
> You added a reference to the non-normative section 3.5 ("Enforcing
> Multiple Policies") when describing normative requirements. I don't
> think the spec should do that; the enforcement of multiple policies
> should be specified in normative text and that normative text should
> be referenced.
>

Hrm. In this case, the non-normative text's entire purpose is to describe
the implications which are implicit in the normative text. The enforcement
mechanisms are specified in normative text (definition of "enforce" at
https://w3c.github.io/webappsec/specs/content-security-policy/#enforce,
plus the "MUST enforce each of the policies" in both the HTTP header field
and <meta> sections).

What would you like to see here to clarify the intent?


> I think browsers should do *something* to help web developers notice
> that they're using <meta> CSP in a problematic way. I can see how my
> original suggestion might be non-trivial to implement. The requirement
> could be worded a different way: The browser must issue a warning
> whenever <meta> is used to deliver a CSP policy in a HTTP- or HTTPS-
> origin document, unless the browser is certain that there's no
> difference between the <meta>-delivered policy and a header- delivered
> one. This would be easy to implement.
>

What does "no difference" mean? The timing is certainly different (which is
the problem in which you've grounded your argument). In which cases would
you expect a message, and in which case would the browser let it go?

> and doesn't really match at least one use case (locking down an
> > application after it "boots").
>
> Are browsers required to support this for CSP2? If so, the spec should
> indicate how it works (it doesn't seem to currently). It would be good
> to have test cases in the test suite for this, if so.
>

The spec monkey-patches HTML's processing of the <meta> element, which is
triggered when the <meta> element is added to the document. Would adding a
note about the implications of JavaScript-driven additions to the DOM be
enough, or would you like additional detail?

Chrome certainly supports this use case, and has test cases (
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/security/contentSecurityPolicy/inline-event-handler-blocked-after-injecting-meta.html&sq=package:chromium
is the first example I could find).

Regardless, I really need to spend some time upstreaming tests to
WebPlatformTests, which is totally on my todo list.

--
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.)