Re: CSP 1.1: Paths in source list definitions.

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