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

RE: Rough sketch of directives for CSP 1.1

From: Hill, Brad <bhill@paypal-inc.com>
Date: Thu, 3 May 2012 16:19:16 +0000
To: Adam Barth <w3c@adambarth.com>, Tom Ritter <tom@ritter.vg>
CC: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E0CB209@DEN-EXDDA-S12.corp.ebay.com>
I think he's asking, if I list  "http://example.com", it should also allow "https://example.com".

We discussed this at TPAC on Day 1.  The notes say that we decided that "example.com" (no scheme) implied both http and https, but explicitly listing a scheme doesn't imply automatic upgrade is allowed.

http://www.w3.org/2011/10/31-webappsec-minutes.html

Current relevant text is:

"4.If the source expression does not have a scheme and if scheme is not a case insensitive match for the scheme of the protected resource's URI, then return does not match."

We could perhaps clarify that for the casual reader a bit more.

> -----Original Message-----
> From: Adam Barth [mailto:w3c@adambarth.com]
> Sent: Thursday, May 03, 2012 9:09 AM
> To: Tom Ritter
> Cc: public-webappsec@w3.org
> Subject: Re: Rough sketch of directives for CSP 1.1
> 
> I'm not sure I understand.  Can you explain what you mean a bit more?
> 
> Thanks,
> Adam
> 
> 
> 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:19:56 GMT

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