Re: An urge for CSP META tag in 1.0

On Tue, May 1, 2012 at 2:36 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
> I understand the concern in concept, but I'm less clear how it could actually result in an elevation of privilege.
>
> For that to happen:
>
> * There must be an injection vulnerability present that allows a META tag to be injected
>        > But not other exploitable script content
>
> * There must be security features in the page that depend on the execution of script in an non-adversarial manner
>        > Framebusting, but any CSP capable browser is also going to support [X-]Frame-Options
>
> * There must not be other ways to disable that script that equally impact the security of the application
>        > NoScript is always a risk for that, though arguably one users impose on themselves
>        > the IFRAME sandbox also offers the ability to disable script
>
> I think the principle that new security features must not make existing applications insecure is important, but if the edge cases are unlikely enough, the security cost of excluding large classes of potential customers from being able to use CSP may be much larger.
>
> Can we come up with a concrete example of a CSP injection creating a security risk?

The report-uri directive could potentially be used to snoop on the
behavior of the page.

Maybe a <meta> tag isn't the best API?  Another option is a JavaScript
API akin to

document.enforceSecurityPolicy("default-src 'self' ");

That's less likely to be injectable (or at least is only injectable in
cases where you're already in trouble).

Adam


>> -----Original Message-----
>> From: Daniel Veditz [mailto:dveditz@mozilla.com]
>> Sent: Tuesday, May 01, 2012 11:45 AM
>> To: John Wilander
>> Cc: public-webappsec@w3.org
>> Subject: Re: An urge for CSP META tag in 1.0
>>
>> On 4/27/12 2:18 AM, John Wilander wrote:
>> > Here are my arguments for bringing support for CSP in meta tags back
>> > into 1.0:
>> >
>> >  1. *Ease of adoption over "perfect" security*.
>>
>> For the developers who want to use CSP meta tag support is a win: it allows
>> CSP use in many more situations such as those you presented in your points
>> 2-4. Combining a content-injection protection policy in the content it's trying
>> to protect carries risk that the policy might be subverted, but I get your
>> argument that it's better than "perfect but not deployed".
>>
>> My main concern is that supporting the meta tag turns CSP into a weapon
>> that can be used against sites who know nothing about CSP and are not
>> trying to protect against it. They may have simple filters trying to block
>> <script> tags and on* event handlers, and get broadsided by a <meta> tag
>> that selectively turns off some of the scripts that are essential to the page --
>> think of some of the attacks on the early versions of IE XSS protection.
>>
>> We should not be adding a "security" feature that makes existing pages less
>> secure if they have not opted into it.
>>
>> -Dan Veditz
>

Received on Tuesday, 1 May 2012 23:09:28 UTC