Bug 92692 - WebKit XSS Auditor bypass
Summary: WebKit XSS Auditor bypass
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Major
Assignee: Nobody
URL: http://www.foundstone.com
Keywords: InRadar
Depends on:
Reported: 2012-07-30 16:43 PDT by research
Modified: 2021-09-21 14:33 PDT (History)
7 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description research 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:


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.


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>

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)

Vendor Response:


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:
Comment 1 Adam Barth 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.
Comment 2 Radar WebKit Bug Importer 2012-08-02 13:18:42 PDT
Comment 3 Eric Seidel (no email) 2012-08-02 13:39:46 PDT
Making public, per Adam's comment.  Thank you very much for the report!
Comment 4 nagarjuna.a 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.
Comment 5 Daniel Bates 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).
Comment 6 Brent Fulgham 2021-09-21 14:33:45 PDT
The XSS Auditor is removed in Bug 230499.