- From: Mike West <mkwst@google.com>
- Date: Sun, 23 Sep 2012 10:27:40 +0200
- To: public-webappsec@w3.org
- Cc: Adam Barth <w3c@adambarth.com>, Odin Hĝrthe Omdal <odinho@opera.com>, tom@ritter.vg
Hello, webappsec! Following up on this followup, two points: 1. An implementation of path support as currently specified in 1.1 landed in WebKit earlier this week[1]. You should already be able to play around with it in WebKit nightlies or Chrome Canary. 2. As Adam suggested[2], we plan to implement path support along with the canonical header[3] once 1.0 hits CR. I'd like some feedback on this plan; it seems like a good idea for the reasons Adam outlined, but I'd appreciate more discussion. [1]: http://trac.webkit.org/changeset/129143 [2]: http://lists.w3.org/Archives/Public/public-webappsec/2012Aug/0007.html [3]: https://bugs.webkit.org/show_bug.cgi?id=96765 -- Mike West <mkwst@google.com>, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 On Mon, Sep 3, 2012 at 3:15 PM, Mike West <mkwst@google.com> wrote: > Hello webappsec! > > Following up on the conversation earlier this summer[1], I've just put > together a first pass at adding paths with directory-level granularity to > the CSP 1.1 draft[2]. I've got a WebKit patch[3] ready that implements paths > as described here; I'll briefly walk through a few high-level choices made > in that patch that might be interesting for discussion here (though, of > course, nothing is set in stone and feedback on the whole concept is > welcome!). > > 1. As defined in this patch, paths represent directories. That is, > `http://example.com/js/` and `http://example.com/js` in source lists will > both whitelist all the files contained in `http://example.com/js/` and its > subdirectories. In particular, this means that > `http://example.com/path/to/file.js` will not whitelist a specific file, but > a directory named `file.js`. Directory-level seemed like the right level of > granularity, and avoids potential confusion between filenames and directory > names by simply picking one and sticking with it. > > 2. Following on from #1, paths explicitly exclude query strings and > fragments. Source expressions containing '?' or '#' are errors, and ignored. > > 3. Paths are minimally normalized: percent-encoded characters are > percent-decoded, but, for example, no effort is made to deal with '.' and > '..' in paths. This is in line with how cookies are specified[4]. > > 4. In a separate patch[5], WebKit added a warning for CSP 1.0 source > expressions that contain paths. I hope that's enough to address Odin and > Tom's versioning concerns from that earlier thread. I'd like to see some > discussion of Adam's 1.0/1.1[6] questions, however, as decisions there will > certainly have an impact on the way we try to implement things going > forward. > > What do you folks think? > > [1]: http://lists.w3.org/Archives/Public/public-webappsec/2012Jul/0000.html > [2]: https://dvcs.w3.org/hg/content-security-policy/rev/abb64ba225c4 > [3]: https://bugs.webkit.org/show_bug.cgi?id=89750 > [4]: http://tools.ietf.org/html/rfc6265#section-5.1.4 > [5]: http://trac.webkit.org/changeset/125047 > [6]: http://lists.w3.org/Archives/Public/public-webappsec/2012Aug/0007.html > > -- > Mike West <mkwst@google.com>, Developer Advocate > Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany > Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Received on Sunday, 23 September 2012 08:28:29 UTC