Re: Meta tag verification

On Fri, Feb 28, 2014 at 5:29 PM, Brad Hill <hillbrad@gmail.com> wrote:

> Well, we don't have a formal use-case document for this, but my
> recollection is that the two primary ones for the feature were:
>
> 1) Non-HTTP transports (e.g. loading from file:///)
> 2) Hosting environments where resource authors can't set headers
>
Yes, but I've talked to a number of developers offline who have stated
their intention to use <meta> policies in their own apps for ease of use.
Additionally, I actually do think there's a legitimate use case for it
given header bloat (especially with script/style-hash whitelists). Maybe
the answer is this is just an unsupported use, though.

>
> I also don't think that guaranteeing the integrity of the tag resolves the
> very concern you mention, about its appropriate placement.  Or is the user
> agent, upon seeing a meta-integrity header, supposed to wait on execution
> until it can make an initial no-op parse to locate the policy, verify it,
> and enforce it from the start of a re-parse?  Sounds bad for perf.
>
It resolves appropriate placement in the sense of disallowing alternate
meta-tag CSP policies; you are correct that it doesn't resolve general
content injection happening before the CSP policy is present. The idea
(perhaps too limiting) is simply that an alternate CSP can't be injected.

That having been said, I could imagine the final spec saying something
like, "if a meta-integrity directive is specified, no script will execute
until the meta-CSP policy is reached." That, it would seem, would at least
stop the XSS case.

>
> -Brad
>
>
> On Fri, Feb 28, 2014 at 5:06 PM, Joel Weinberger <jww@chromium.org> wrote:
>
>> For a while now, I've had rather mixed feelings about CSP in the meta
>> tag. Namely, it seems a little too easy to shoot oneself in the foot by
>> doing something as simple as putting a title tag with user content above it.
>>
>> That having been said, I've also been recently convinced that it's
>> probably necessary. Header bloat is getting out of control, plus it's much
>> easier to manage.
>>
>> So why not get the best of both? I propose a meta-integrity CSP directive
>> (that's HTTP header only) that holds a hash of the CSP policy in the meta
>> tag. This would guarantee that the meta tag CSP is the one the server
>> intended. This would eliminate all of the concerns I've heard of about the
>> meta tag, while still providing its flexibility.
>>
>> Personally, I'd go one step further and mandate that a meta-integrity be
>> present in the HTTP header if the developer wants to use a meta tag CSP,
>> but I suspect developers might find that overbearing.
>>
>> Any thoughts on all of this?
>> -Joel
>>
>
>