Re: An urge for CSP META tag in 1.0

On 5/1/12 4:08 PM, Adam Barth wrote:
> 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
>
If we did this, then pages that wanted to implement CSP would have to 
allow inline script, wouldn't they?  Or would we require that the 
enforceSecurityPolicy script must be in the head, must be the first node 
in the head, cannot be overwritten by script found later in the page, etc?

We could restrict report-uri to the header only (as you suggested).  
Developers would have to rely on their own testing using existing 
browser features and addons.  If they want more extensive reports in the 
future, they would have to switch to the header.  This would give 
developers time to tune their CSP until they think they have it right, 
and then ask their sysadmins to make a one time change to add the header 
(instead of multiple changes until their policy is perfect).

If we do support the meta tag, I believe it should be the first node in 
the <head>.  This mitigates the threat of script before the meta tag 
creating it's own, more relaxed policy.

~Tanvi

>>> -----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 Wednesday, 2 May 2012 15:07:56 UTC