- 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>
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 UTC