CSP 1.1: More granular source list definitions.

Currently, the path component of a source should simply be thrown away
(e.g. `script-src
https://example.com/path/to/`<https://example.com/path/to/>would match
both `
https://example.com/path/to/file.js` <https://example.com/path/to/file.js>and `
https://example.com/otherfile.js` <https://example.com/otherfile.js>).

One of the proposals for CSP 1.1 is additional granularity in source paths (
http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1).
I
think this additional granularity is well worth perusing, and I've started
on a strawman implementation for discussion (
https://bugs.webkit.org/show_bug.cgi?id=89750) . I've started with the
simplest possible implementation, which simply performs a substring match
on the resource's path. That is, given the following directive:

    script-src https://example.com/path/to/

the following resources would load:

    https://example.com/path/to/file.js
    https://example.com/path/to/anotherfile.js

while the following would fail:

    https://example.com/anotherpath/to/file.js

So far, this seems straightforward. I have two questions about corner cases:

1. What ought to be done with the following:

    script-src https://example.com/path/to

Should this match `https://example.com/path/to/file.js`? Should it match `
https://example.com/path/todo/file.js`? One method of resolving this
ambiguity would be with an explicit wildcard at the end of a path
declaration, much like we currently support at the beginning of hosts. Does
`script-src https://example.com/path/to/*` look reasonable? Should we
interpret a trailing slash as implicitly being followed by a wildcard?

2. Should query strings be handled differently? Should `script-src
https://example.com/path/to/file.js` match `
https://example.com/path/to/file.js?query=string`?

Thanks!

--
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 Friday, 22 June 2012 09:32:37 UTC