Foundstone Security Advisory
Advisory Title: Webkit XSS Auditor bypass
Author: Tushar Dalvi
Release Date: 19-07-2012
Application: All versions of Google Chrome (4 and above), Safari (5.1.7, lower versions not tested yet)
Platform: All supported platforms
Since Google Chrome 4, a feature was added to help mitigate reflective XSS. The XSS filter is similar to those found in Internet Explorer 8 and NoScript. The XSS filter checks whether a script that's about to run on a web page is also present in the request that fetched that web page. If the script is present in the request, that's a strong indication that the web server might have been tricked into reflecting the script.
Instead of being layered on top of the browser like IE8 XSS Filter and NoScript, this XSS filter is integrated into WebKit. Google Chrome and Safari both rely on Webkit to render the pages.
There is currently no check in the XSS Auditor to determine the context where the data is reflected in the response. Following are the 5 output contexts:
1. HTML entity
2. HTML Attribute
var foo = "<%= request.getParameter("foo") %>";
document.write("<text>Welcome "+ foo + "</text>");
Sample URL : www.domain.com/test.jsp?foo=2"; alert(document.cookie); var a="1
The same URL was tested against different browsers which implement similar filters to block XSS attacks.
Internet Explorer 8.0 with XSS filter enabled, detected and blocked the attack.
Mozilla Firefox 14.0.1 with Noscript 2.4.8, detected and blocked the attack.
Safari 5.1.7, failed to detect the attack and executed the script. (This is because Safari implements the same webkit XSS auditor as Google Chrome)
The XSS Auditor could possibly be modified to understand the context where the reflected data is being dumped, and apply a different logic to determine the intent of the data relative to that context, to better prevent reflected XSS attacks.
For questions and comments please send an email to:
I'm inclined to make this bug public in case any contributors who don't have security access want to work on this issue.
Making public, per Adam's comment. Thank you very much for the report!
Seems to be this is fixed in latest Chrome versions.
Please provide the patch for understanding the logic.
(In reply to comment #4)
> Seems to be this is fixed in latest Chrome versions.
> Please provide the patch for understanding the logic.
Can you elaborated on how you tested? I am able to reproduce this issue by following the instructions in comment 0 in Chrome Canary for Mac version 57.0.2956.0 canary (64-bit).