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

On Fri, Mar 30, 2012 at 9:02 AM, Daniel Veditz <dveditz@mozilla.com> wrote:
> 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?

Having worked with folks who build large, complex web applications, I
can tell you that they all wind up using the <meta> element when
introducing CSP into their applications.  The exact reasons vary from
application to application, but they find the flexibility to choose
when in the application boot process to engage the policy valuable.

Now, we could tell these folks that they need to get their entire
application from start-to-finish ready for CSP before they can realize
any of the benefits, but the end result is that their use of CSP will
be delayed, likely indefinitely.  Instead, if we give them a way to
realize some benefits today and a path towards realizing more benefits
in the future (i.e., by engaging CSP earlier and earlier), my
experience is that this is enough of a carrot for them to start
implementing now.

In any case, this sounds like it's a bit too controversial for CSP
1.0.  IMHO, we should take <meta> out of the spec for now and discuss
the use cases more for CSP 1.1.

Adam


> 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 22:54:04 UTC