---Google:"Chrome 18 anti XSS bypass" and feel lucky ;) A while ago I released a bypass for the webkit XSSAuditor in Chrome, I thought I'd honor it with a blog post and discuss another danger the XSSAuditor presents to web application security. This 'danger' of XSS filters has been published in a very popular paper---http://www.collinjackson.com/research/xssauditor.pdf--- about some XSS filters. What I'm doing here is demonstrating whats described. XSSAuditor is part of XSSAuditor is part of WebKit's HTML parser and exists to try and mitigate reflected XSS attacks . Unfortunately because of how the auditor operates it can often have quite the opposite effect!

In this post I'll explain the situations where XSSAuditor can actually have the adverse effect on a web application's protection against XSS attacks.

How does it work?

Before getting down to business we need to cover a little admin, I should first make it clear exactly how the XSSAuditor goes about its job.

The XSSAuditor is a small part of WebCore the collection of things in WebKit that handle parsing HTML,XML and Javascript---among other things.

Its been designed to inspect requests and responses for anything that resembles runnable Javascript. Should a response and request contain exactly the same runnable Javascript, the XSSAuditor will remove said Javascript from the response. Please take note of the way that last sentence was phrased. The XSSauditor will only

inspect:

Responses



Requests---GET and POST

Audit

Responses

www.vulnerable.com/script.php?arg=<script>alert("Woops!");</script>

XSS attack Blocked by XSSAuditor

<script>/*alert("Woops");*/</script>

Reverse Engineering Server side XSS filters I must make myself clear when I say "Server Side XSS filters", I'm referring to server side filters that strip out dangerous payloads from requests before returning them.

Because of the way the XSSAuditor operates, its possible to use these server side filters to propagate XSS attacks! If you think about it a lil it because pretty obvious. An attacker injects some payload A with malicious content q

This payload is audited by the server and returned as A - q

XSSAuditor tries to match A with A - q, this fails and the returned payload is left untouched! It may not be apparent why this is dangerous, you're probably arguing that

if you inject a payload and the server removes all the good bits, why would it still be dangerous in the request?



To prove that we can create attacks using these properties, I'll pose a not so hypothetical situation.



DVWA has an example of XSS attacks against scripts that behave the same way, I'm going to attack it with a non-malicious payload, and have it return a malicious one all while bamboozling the XSSAuditor into allowing the payload to take effect, here's the for the script I'll will be attacking:



str_replace('<script>','',$_GET['name']);

This will remove the string <script> from the payload. So what I'll do with this is inject something like:

<scr<script>ipt>ale<script>rt(1);</script> The first bolded <script> string is to make sure that the server side filter will not remove our opening <script> tag, but infact strip away the "bold" <script> leaving a valid opening script tag behind. The second one is there so that the XSS auditor will see:

ale<script>rt(1); in the request

and alert(1) ; in the response This means it will not find a match between the two, and leave the response to be parsed by the WebCore.

This example is quite simplistic though I'm confident that code like this does occur in the some of the web applications out there---I know you haz em! Another thing to take into account is the average blacklist or regex that is to perform a similar action---remove dangerous string tokens from input---will most probably try to match a list of tags, not just <script>, unless the developer knows absolutely nothing about XSS attacks. Lets check out how the payload behaves: XSSAuditor says what!? As expected! Also keep in mind that we are not just talking about Server Side filters only here, we could be talking about IDS's or WAFs I'm sure some of you will be able to think up tons of examples where applications behave the same way.

Oh for those of you who are wondering I used Chrome Version 19.0.1084.52 to do the demo.





The most shocking part about all this is the XSSAuditor is supposed to protect users but what It's doing here is actually helping propagate attacks! Solution? FireFox + NoScript ;)

That's it for now! Hope you enjoyed it, feel free to flame me with some comments if the post has some spelling/logic or grammatical errors lols.

It may not be apparent why this is dangerous, you're probably arguing thatif you inject a payload and the server removes all the good bits, why would it still be dangerous in the request?To prove that we can create attacks using these properties, I'll pose a not so hypothetical situation.DVWA has an example of XSS attacks against scripts that behave the same way, I'm going to attack it with a non-malicious payload, and have it return a malicious one all while bamboozling the XSSAuditor into allowing the payload to take effect, here's the for the script I'll will be attacking:The critical part here isThe first bolded string is to make sure that the server side filter will not remove our opening <script> tag, but infact strip away the "bold" <script> leaving a valid opening script tag behind. The second one is there so that the XSS auditor will see:This means it will not find a match between the two, and leave the response to be parsed by the WebCore.

IF and ONLY if the same runnable javascript is detected in both---. Whether they are the same is down to whether the cpp string method `find' will match the data in both requests and responses---So lets take a look at the XSSAuditor in action, what it does and when.Once again I'll be using DVWA to do the demo.I'm gonna use a straight forward payload, something like:So in the above screen shot you can see the effect XSSAuditor has on the injection payload. Its managed to match the payload in BOTH the request and response and is stripped out the contents of the script tag. You may wonder why it doesn't just completely kill the entire payload, why would it keep the script tags?Oh yes, why keep the script tags? This is done so that the Auditor affects as little of your browsing experience as possible, it will only remove what it deems dangerous, but keep the rest of the returned HTML tokens in attribute values in case the Web Page needs them for some reason.So yeah that's what does. You may want to see that I'm serious when I say "RUNNABLE" javascript---will be audited. To prove my point, ill inject some non-runnable javascript---Here's the Payload:And the screen shot :)The payload remains untouched! If you inject commented and non-commented javascript the entire contents of the script tags will be removed.So now you guys know a lil about what the auditor does, I can move onto explaining what it doesn't do!We know that the XSSAuditor STRIPS out the javascript, if it sees the same javascript in the response and the request. This obviously implies that if it cannot match the javascript in the request, it will not strip it out---So this means if something happens to the injected javascriptbefore it reaches the browser the XSSAuditor would touch it. I'm talking about cases when the web application you're attacking mangles or changes the payload before returning it. This particularly dangerous when the application returns the payload in a form thats different from it is in the request but still runnable. Now I know that this doesn't likely occur in modern applications, I've stated it this way because it provides a good stepping stone to move onto the next topic.