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>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]
> Sent: Wednesday, November 28, 2012 10:01 AM
> To: Fred Andrews
> Cc: Hill, Brad; 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> 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
> > To: 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 , positive feedback is
> > encouraged.
> >
> >
> >
> > This CfC will end on December 4, 2012.
> >
> >
> >
> > Thank you,
> >
> >
> >
> > Brad Hill
> >
> >
>
>
>
>


-- 
-Eric

Received on Wednesday, 28 November 2012 01:03:51 UTC