RE: [webappsec] Call for Consensus: CSP 1.1 to FPWD

>> The advantage of this solution lies in its usability. Site authors can allow "trusted" inline scripts to execute before turning on CSP, they also don't need to whitelist any external scripts added before the <meta> injection point.

>> I'm not sure if there is another way to accomplish this so I would like to keep this discussion open before removing <meta> entirely from CSP.

This type of design complicates the implementation considerably (enabling mutability of the restrictions on a document), which could increase the surface area for implementation bugs (leading to vulnerabilities in the design).  It also could lead to author mistakes (accidentally including a 3rd party script above the <meta> tag).

In the past, Microsoft has gotten negative feedback from authors for <meta> tags that have restrictions or special behavior based on their ordering with respect to other tags in the document. The example that comes to mind was our X-UA-Compatible meta tag, which can be used to change the rendering engine in IE for compatible behavior with legacy versions of the browser.  It must be placed before certain other types of elements in the head, otherwise it is ignored. This has led to author confusion and even compatibility issues where sites did not get the correct behavior because the tag was not placed in the correct order.

My preference would be to recommend authors simply include all scripts as external and with exceptions for them in the CSP. This reduces the complexity and  ensures utmost clarity in the behavior (avoiding mistakes).

From: Eric Chen [mailto:eric.chen@sv.cmu.edu]
Sent: Tuesday, November 27, 2012 5:03 PM
To: Jacob Rossi
Cc: Adam Barth; Fred Andrews; Hill, Brad; public-webappsec@w3.org
Subject: Re: [webappsec] Call for Consensus: CSP 1.1 to FPWD

There is a good use case for the <meta> element that cannot be addressed by a non-injectable <html> attribute. Imagine a lightweight deployment of CSP where the site author trusts all the content from the initial page load (let's assume there is already some sanitization framework deployed on the server), and the site author wants to enable CSP after the DOM is fully loaded to protect her site from DOM XSS (type-0 XSS). One easy way to do this is injecting a <meta> tag after the "DOMContentLoaded" event to prevent any newly injected scripts from executing.

I have a proof-of-concept of this here: http://code.google.com/p/dominatrixss-csp/

The advantage of this solution lies in its usability. Site authors can allow "trusted" inline scripts to execute before turning on CSP, they also don't need to whitelist any external scripts added before the <meta> injection point.

I'm not sure if there is another way to accomplish this so I would like to keep this discussion open before removing <meta> entirely from CSP.

On Tue, Nov 27, 2012 at 4:16 PM, Jacob Rossi <Jacob.Rossi@microsoft.com<mailto:Jacob.Rossi@microsoft.com>> wrote:
I agree with this feedback. An HTML element attribute would solve a few of the problems we've noted about <meta>.  I do not think this needs to block FPWD as it doesn't affect the feature scope of the spec (which is the primary thing I look for when deciding to publish a FPWD).

I support a publication of CSP 1.1 as FPWD.

-----Original Message-----
From: Adam Barth [mailto:w3c@adambarth.com<mailto:w3c@adambarth.com>]
Sent: Wednesday, November 28, 2012 10:01 AM
To: Fred Andrews
Cc: Hill, Brad; public-webappsec@w3.org<mailto:public-webappsec@w3.org>
Subject: Re: [webappsec] Call for Consensus: CSP 1.1 to FPWD

On Tue, Nov 27, 2012 at 3:45 PM, Fred Andrews <fredandw@live.com<mailto:fredandw@live.com>> wrote:
> Dear Brad,
>
> Using a <meta> element for the CSP is problematic and I recommend it
> be moved to an attribute on the <html> element.  Further I recommend
> that injection of such an attribute be ignored so that only the static
> markup can have any effect.
>
> Using a <meta> element opens a range of complex issues, such as
> synchronizing the start of a CSP with ongoing asynchronous page load
> actions and the retrospective application of restrictions to running JS contexts.
> To make it reliable might require the introduction of a dependency
> notation and this may not be worth the effort.

This is good feedback for the working group for after we've published a FPWD.  Perhaps we should raise an ISSUE so that we're sure to address your concerns before moving to the next stage of the W3C process.

Adam


> The security work of PUA CG requires a static mechanism for specifying
> the CSP to avoid the initiation of the CSP being used to leak
> information and a <html> attribute will likely be used to avoid having to reading ahead for a
> CSP <meta> element.   This appears much easier to implement and would be a
> subset of the proposed CSP 1.1 <meta> element and perhaps it would be
> adequate and better suit browser vendors anyway.
>
> cheers
> Fred
>
> ________________________________
> From: bhill@paypal-inc.com<mailto:bhill@paypal-inc.com>
> To: public-webappsec@w3.org<mailto:public-webappsec@w3.org>
> Date: Tue, 27 Nov 2012 22:01:20 +0000
> Subject: [webappsec] Call for Consensus: CSP 1.1 to FPWD
>
>
> This is a Call for Consensus among the WebAppSec WG to accept the
> following draft of CSP 1.1 as a First Public Working draft:
>
>
>
> https://dvcs.w3.org/hg/content-security-policy/raw-file/48bed86c418d/c
> sp-specification.dev.html
>
>
>
> CSP 1.1 extends CSP 1.0 and defines several new elements of policy
> mechanism:
>
>
>
> * an HTML <meta> Element
>
> * Script Interfaces
>
> * Directory path Source Expressions
>
> * Media Type lists
>
>
>
> As well as a number of new directives:
>
>
>
> * form-action
>
> * script-nonce
>
> * plugin-types
>
> * reflected-xss
>
>
>
> Please send comments to public-webappsec@w3.org<mailto:public-webappsec@w3.org> , positive feedback is
> encouraged.
>
>
>
> This CfC will end on December 4, 2012.
>
>
>
> Thank you,
>
>
>
> Brad Hill
>
>





--
-Eric

Received on Wednesday, 28 November 2012 01:59:11 UTC