Re: [CSP] <meta> clarifications

Mike West <mkwst@google.com> wrote:
> Brian Smith <brian@briansmith.org> wrote:
>> 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?

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

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

>> 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?

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

> 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?

<snip>

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

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?

Cheers,
Brian

Received on Monday, 19 January 2015 17:38:42 UTC