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

Re: Rough sketch of directives for CSP 1.1

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 3 May 2012 09:08:48 -0700
Message-ID: <CAJE5ia_=BNfW-kheDDBOuMsFHLUS1a6qksMV1YtKVbYqKjN0wA@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Cc: public-webappsec@w3.org
I'm not sure I understand.  Can you explain what you mean a bit more?


On Thu, May 3, 2012 at 9:05 AM, Tom Ritter <tom@ritter.vg> wrote:
> Is there a way currently to say "http on the standard port implies
> https on its standard port" for the source list?  If not, I think
> that'd be nice.
> -tom
> On 3 May 2012 01:05, Adam Barth <w3c@adambarth.com> wrote:
>> 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 16:09:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:28 UTC