Re: CSP 1.1: Paths in source list definitions.

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
/js/thisfile.php?get=that

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
/js/thisfile.php?get=../stupid/hack.php


... 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