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

Re: CSP 1.1: Paths in source list definitions.

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Tue, 16 Oct 2012 11:57:53 +0200
Cc: "Adam Barth" <w3c@adambarth.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Tanvi Vyas" <tanvi@mozilla.com>
To: "Mike West" <mkwst@google.com>, "Dan Veditz" <dveditz@mozilla.com>
Message-ID: <op.wl9nar1r49xobu@odinho-fido.oslo.osa>
Dan Veditz wrote:
> On 10/15/12 7:35 AM, Mike West wrote:
>> I think he means the opposite: whitelisting 'example.com/js/thisfile.js
>> <http://example.com/js/thisfile.js>' would allow
>> 'https://example.com/js/thisfile.js?29', etc. We'd simply ignore the
>> query portion of the source expression.
> Yes, I think we have to do that. While sites do return different
> resources in response to different queries, in many cases the arguments
> are not order sensitive or are optional. The next CSP feature request
> would be some complex regular expression syntax for matching parts of
> the query string -- yuck.

Okay :-) I guess that might be the least surprising thing to do. Not
possible to lock it down though.

In the other case, you'd have to allow /js/ if you wanted

Authors would probably be a bit confused why restricting to
/js/thisfile.php didn't allow a query string. So I agree.

It would be possible to do the opposite though, requiring more information
to restrict even further; that is, if I never wanted query parameters to
be used for my js file, I could do   /js/thisfile.js?  and the question
mark would signify that only requests to /js/thisfile.js? and
/js/thisfile.js would be allowed.

Similarly if I have a PHP-script I could nail down to only allow requests
with certain queries, like so  /js/thisfile.php?get=onlythat, then it'd
only allow that string, and not /js/thisfile.php nor

... But. I think we can do without.

Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Tuesday, 16 October 2012 09:58:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:29 UTC