- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Thu, 20 Jan 2011 14:49:52 -0800
- To: Brandon Sterne <bsterne@mozilla.com>
- Cc: Adam Barth <w3c@adambarth.com>, public-web-security@w3.org, Sid Stamm <sid@mozilla.com>, Lucas Adamski <ladamski@mozilla.com>
Oh, and I noticed that CSP specifies allowable script locations on per-origin basis too. That would make it vulnerable to the two attacks I mentioned in my initial response to Adam, right? Specifically, consider that within any medium-complexity domain (mozilla.com, google.com, facebook.com), you can almost certainly discover a location that returns HTML-escaped attacker-supplied text in a context that would parse as valid JavaScript. This is easier than expected particularly in browsers that support E4X - such as Firefox. If I have a 404 HTML page saying: <html><body> ... The page at $escaped_request_location cannot be found. ... </body> </html> ...and $request_location = "/some/path/{alert(1)}", then user-supplied script will execute. To test, try this in Firefox: javascript:void(<html>foo {alert(1)}</html>) So, if origin-wide script inclusion is permitted, I can probably inject this: <script src="http://allowed_origin/nonexistent/path/{alert(1)}"></script> ...and have my payload execute under CSP and under Adam's proposal. In browsers that don't support E4X, this is probably also exploitable in many cases, especially with text/plain responses, hosted files, etc - just marginally harder. This can be fixed by strictly enforcing Content-Type. But it won't help you with another case: http://allowed_origin/some_unrelated_public_js_api?callback=attacker_selected_function ...which is intended to be included on third-party sites via <script src=...>, and returns application/x-javascript structured this way: attacker_selected_function('api_provided_values') Such APIs are common on a variety of sites. Google Maps are probably a good example, but I also expect Twitter, Facebook, etc, to have something along these lines. Am I correct on this? I honestly think we should be putting a lot more emphasis of understanding actual use cases in complex environments for any security mechanisms proposed; coming up with unified frameworks, rather than disjointed solutions for small subsets of problems (CSP is a step in a good direction, but has some shortcomings); and engaging a far broader security community... I know this is not a productive complaint, and probably not a welcome one, but... :-) /mz
Received on Thursday, 20 January 2011 22:50:46 UTC