- From: Odin Hørthe Omdal <odinho@opera.com>
- Date: Tue, 16 Oct 2012 11:57:53 +0200
- To: "Mike West" <mkwst@google.com>, "Dan Veditz" <dveditz@mozilla.com>
- Cc: "Adam Barth" <w3c@adambarth.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Tanvi Vyas" <tanvi@mozilla.com>
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