- From: Tom Ritter <tom@ritter.vg>
- Date: Thu, 3 May 2012 12:05:33 -0400
- To: Adam Barth <w3c@adambarth.com>
- Cc: public-webappsec@w3.org
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:06:27 UTC