Re: Header Policy Vs. Meta tag policy

On 6/9/2014 9:50 PM, Mike West wrote:
> I'd prefer to maintain the ability to tighten a page's policy, as I
> think there are totally valid use cases for such a thing, but so far
> I've been the only one in favor of that, and the spec reflects my
> understanding of the group's consensus.

There are definitely good and valid use cases for tightening a site-wide 
header policy via <meta> document policy. The concern was whether an 
injected <meta> policy can break a site that was otherwise not broken, 
much as people were able to use early versions of the XSS filtering in 
IE to cause security problems on (a very few) sites that otherwise were 
not broken.

Turning off an entire site's scripts in CSP 1.0 was not likely to do 
anything other than break the page, but with CSP 1.1's support of path 
whitelisting you could theoretically intersect a header policy of 
script-src 'self' with an injected policy that whitelists individual 
self-hosted scripts except for the one whose omission will leave some 
important checks undone.

That's the fear--but I guess it all hinges on the fact that the victim 
site did have an injection problem. If there's no header CSP the site 
loses anyway (why inject <meta> when you can inject <script>?). If there 
is a header CSP and we allow <meta> policies there's a slight risk of 
being able to open a security hole. It's tempting to just blame the site 
with the injection problem, but presumably if they were confident in 
their perfection they wouldn't need to be using CSP.

We could add a 'no-meta' header directive--or more generally a 
'final-policy' that could help protect against the slight risk of header 
injection--but I don't realistically expect anyone to use them so I'm 
not seriously proposing it.

I withdraw my objection to combining header and <meta> CSP.

-Dan Veditz

Received on Wednesday, 11 June 2014 05:57:22 UTC