W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2012

Rough sketch of directives for CSP 1.1

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 2 May 2012 22:05:48 -0700
Message-ID: <CAJE5ia-wmVDr4UHZLcd6L_2L5=tDEK-O-ZE8uihjTzJkDGXoNA@mail.gmail.com>
To: public-webappsec@w3.org
At the face-to-face today, we talked through the proposed directives
on the wiki page:

http://www.w3.org/Security/wiki/Content_Security_Policy

The sense I got from the room was that there was significant interest
in the following set of directives, so I moved them to the "Proposals
for Version 1.1" section of the wiki:

* sandbox.  This directive was in CSP 1.0, but it's looking like we're
going to move it to CSP 1.1 so that we can move CSP 1.0 along the W3C
process faster.

* The ability to convey a CSP policy in a <meta> tag.  This used to be
in the CSP 1.0 spec, but was punted because it needed some further
polishing.  We talked it over at the face-to-face and generated some
good ideas for how to improve on the previous design.  I'll post more
details once I write them up in a coherent way.

* A DOM API for reading the policy, likely something akin to
<https://mikewest.org/2012/05/content-security-policy-feature-detection>.

* script-nonce.  This directive lets sites further lock down scripts
by requiring that <script> elements need to both satisfy the
script-src directive AND have an attribute containing a nonce declared
by the script-nonce directive.

* frame-ancestor and/or frame-options.  We should coordinate with the
IETF websec working group on Frame-Options to see whether it makes
more sense for that to be a CSP directive rather than
yet-another-security-policy-in-an-HTTP-header.

* form-action.  This directive lets site restrict which URLs can be
used as the actions of forms.  In Postcards from the post-XSS world
<http://lcamtuf.coredump.cx/postxss/>, lcamtuf previews for us the
kinds of XSS attacks sites will need to deal with after deploying CSP.
 The form-action directive helps with some of these and fits nicely in
with the CSP 1.0 directives, so it seems like a win.

* plugin-types.  This directive lets sites provide a whitelist of
plugin MIME types they allow.  For example, a site could whitelist
Flash, thereby excluding Google Gears.  Some folks wanted to be able
to specify which MIME types were acceptable from which origins, but we
couldn't come up with an elegant syntax.

* More granular source like (e.g., by directory).  Rather than
whitelisting an entire origin, sites might wish to whitelist only
certain directories within those origins.  For example,
      script-src https://example.com/js; style-src https://example.com/css
There's some question about whether how we want these sorts of
policies to be interpreted by a CSP 1.0 compliant user agent.  We
might need to tweak the CSP parser slightly to make this work well.

Please note that this is just a very rough sketch of which directives
we're going to work on for CSP 1.1.  Please feel encouraged to send
ideas for new directives to the list and to add them to the wiki.  If
you hate these directives or love other directives, please also feel
encouraged to make your feelings known.  :)

Thanks!
Adam
Received on Thursday, 3 May 2012 05:16:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 3 May 2012 05:16:56 GMT