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

CSP 1.1: Paths in source list definitions.

From: Mike West <mkwst@google.com>
Date: Mon, 3 Sep 2012 15:15:52 +0200
Message-ID: <CAKXHy=fKF5b4Q1aBnjVV86daCtf7qEZxo+MaikFvOjmoD+RtmA@mail.gmail.com>
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 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 Monday, 3 September 2012 13:16:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 3 September 2012 13:16:46 GMT