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

On Fri, Mar 30, 2012 at 3:53 PM, Adam Barth <w3c@adambarth.com> wrote:
> 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.

I've removed the <meta> element mechanism for conveying policy in:

http://dvcs.w3.org/hg/content-security-policy/rev/59ec5f6bac1a

I'm hopefully we'll address these use cases in 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 Sunday, 1 April 2012 23:09:30 UTC