92692 2012-07-30 16:43:01 -0700 WebKit XSS Auditor bypass 2016-12-19 13:07:39 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) All All NEW http://www.foundstone.com InRadar P3 Major --- 1 research webkit-unassigned abarth dbates eric nagarjuna.atluri tsepez webkit-bug-importer oldest_to_newest 682524 0 research 2012-07-30 16:43:01 -0700 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 682533 1 abarth 2012-07-30 16:52:33 -0700 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. 685715 2 webkit-bug-importer 2012-08-02 13:18:42 -0700 <rdar://problem/12019108> 685751 3 eric 2012-08-02 13:39:46 -0700 Making public, per Adam's comment. Thank you very much for the report! 969047 4 nagarjuna.atluri 2014-01-16 22:33:57 -0800 Seems to be this is fixed in latest Chrome versions. Please provide the patch for understanding the logic. 1261187 5 dbates 2016-12-19 13:07:39 -0800 (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).