RESOLVED WONTFIX 92692
WebKit XSS Auditor bypass 
https://bugs.webkit.org/show_bug.cgi?id=92692
Summary WebKit XSS Auditor bypass
research
Reported 2012-07-30 16:43:01 PDT
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
Attachments
Add attachment proposed patch, testcase, etc.
Adam Barth
Comment 1 2012-07-30 16:52:33 PDT
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.
Radar WebKit Bug Importer
Comment 2 2012-08-02 13:18:42 PDT
<rdar://problem/12019108>
Eric Seidel (no email)
Comment 3 2012-08-02 13:39:46 PDT
Making public, per Adam's comment. Thank you very much for the report!
nagarjuna.a
Comment 4 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.
Daniel Bates
Comment 5 2016-12-19 13:07:39 PST
(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).
Brent Fulgham
Comment 6 2021-09-21 14:33:45 PDT
The XSS Auditor is removed in Bug 230499.
Note You need to log in before you can comment on or make changes to this bug.