Re: Rough sketch of directives for CSP 1.1

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