Re: [webappsec] CSP META tag support - keep or remove?

On 3/27/12 3:06 PM, Adam Barth wrote:
> Let's number the use cases for easy reference (from Brad's message):
> 
> 1) Support static documents loaded by file: , data: or other non-HTTP methods

Not a common case. A more compelling "web" use-case is for
situations where authors are given space for content but no control
over the headers served (example: blog hosting services, the old
Geocities). At Mozilla we were sad to give this case up when we
decided policy-uri was safer than a <meta> tag.

> A) Support only use cases (1) and (2) and require user agents to
> ignore <meta http-equiv> element outside the head.

Doesn't the HTML5 spec already require this? Although case 3) is a
bad idea you can still do quite a bit of processing in the <head> if
you left the <meta> CSP to the last.

> B) Support use case (3) via another mechanism.  For example, we can
> add a DOM (like document.contentSecurityPolicy) that can be used to
> add a policy at run time.

This takes us even further down the road from a declarative security
policy to a dynamic one.

> C) Suppose use cases (1), (2), and (3) using a non-http-equiv <meta> element.

http-equiv or not, why does case (3) require such late application
of the security policy? Putting a security mechanism intended to
combat content-injection inside content presumably vulnerable to
injection seems sketchy to start. The <head> is dangerous enough but
the actual <body> is where the bulk of the injection attacks occur.

The whole argument against policy-uri came down to "people might
unknowingly do something slow" but in-content policy is a
foot-gun where people might unknowingly do something stupidly
insecure. It also gives attackers a new tool to use against old
content that isn't likely to be sanitizing their content against
this feature, something similar to the script-disabling attacks
against the early version of the IE XSS filter. It's especially sad
when a security feature is used to make a page less secure.

-Dan Veditz

Received on Friday, 30 March 2012 16:03:41 UTC