Bug 92692 - WebKit XSS Auditor bypass
: WebKit XSS Auditor bypass
Status: NEW
: WebKit
New Bugs
: 528+ (Nightly build)
: All All
: P3 Major
Assigned To:
: http://www.foundstone.com
: InRadar
:
:
  Show dependency treegraph
 
Reported: 2012-07-30 16:43 PST by
Modified: 2014-01-16 22:33 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-07-30 16:43:01 PST
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
Severity: High
Vendor status:

Overview:

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.
An attack vector exists which bypasses the XSS auditor filter, and execute arbitrary javascript in the context of the loaded page.

Details:

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
3. JavaScript
4. CSS
5. URL

The issue arises when the data is reflected back into the Javascript context. Following is an example of a test file used to demonstrate the weakness:
Filename: test.jsp

<html><head><title>Test Page</title></head>
<body>

<script>
var foo = "<%= request.getParameter("foo") %>";
document.write("<text>Welcome "+ foo + "</text>");
</script>
</body>
</html>


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)

Vendor Response:


Recommendation:

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:
research@foundstone.com
------- Comment #1 From 2012-07-30 16:52:33 PST -------
Yeah, we'd like to handle injection into string contexts in JavaScript, but we don't currently handle that injection vector.  Thanks for the report.

I'm inclined to make this bug public in case any contributors who don't have security access want to work on this issue.
------- Comment #2 From 2012-08-02 13:18:42 PST -------
<rdar://problem/12019108>
------- Comment #3 From 2012-08-02 13:39:46 PST -------
Making public, per Adam's comment.  Thank you very much for the report!
------- Comment #4 From 2014-01-16 22:33:57 PST -------
Seems to be this is fixed in latest Chrome versions.
Please provide the patch for understanding the logic.