W3C home > Mailing lists > Public > public-web-security@w3.org > January 2011

Re: XSS mitigation in browsers

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Thu, 20 Jan 2011 14:49:52 -0800
Message-ID: <AANLkTimVQwZ-bcaVpZO6jpchZSBA417aHsiVtiaKFTZ6@mail.gmail.com>
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:

The page at $escaped_request_location cannot be found.

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


...which is intended to be included on third-party sites via <script
src=...>, and returns application/x-javascript structured this way:


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

Received on Thursday, 20 January 2011 22:50:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:25 UTC