Bypassing Chromes XSS Auditor

Webz · April 21, 2016

Since @brutelogic and I have had a lot of fun bypassing filters, creating challenges and finding new XSS methods and payloads in the past we thought we should try our luck on Chrome’s Auditor. You can read about the results of our research here. The bypasses we found can be used in many cases but there might be some situations where you can’t use them, for example when there’s no closing script tag or with some special chars after the actual payload like > or ?. However, there are some uncommon ways you could try.

No closing script tag:

When there’s no closing script tag our bypasses won’t work. They need at least one ” somewhere after the payload and </script> anywhere on the page after our injection. But there’s still a way to defeat the filter. We just have to use HTML imports. They will also be important for an uncommon bypass I’ll explain later. Their syntax is very simple:

In href we can specify any link we want as long as it doesn’t violate SOP. CORS might help here. Any link except one to a local resource is usually blocked by Chrome’s auditor. However if we use our known bypass we used with script src we are able to include a data: url. Our new payload would be

We have to use html entities, otherwise our payload is flagged. This is possible as we are inside an href attribute now. [test]

auditor bypass with html import

Working without being flagged

This actually works in the sites context and would alert the domain name. No user interaction or closing script tag required.

Local html inclusion

This also relies on our link tag, but this time we play by the rules of the auditor. As I mentioned earlier we are only allowed to include local resources. The content type isn’t really important as this would also work with X-Content-Type-Options: nosniff. This gives us an interesting bypass opportunity. When we have an upload feature on the website where we want to inject our payload we can use it to upload a file with html code in its source. For example a .gif file with the content

GIF89a<script>alert(1)</script>

More info about that here, here and here. Even imgur would accept such a file (even though it can’t be displayed). Here’s the proof:

imgur accepts this as a valid gif file

Now let’s include it. We do this with

And there we go. It works! [test]

Working great (DOM view)

Multiple reflections

That’s a whole different class of bypasses than the ones we’ve seen before. It’s not working due to an unclosed quote or the fact that the auditor trusts local resources that are passed without parameters. It is possible because the auditor sees a request with some html tags that look harmless on their own, but can be malicious if they occur more than once. This is usually achieved with script tags.

A simple example where this would work is this:

<a href = "INJECTION">INJECTION</a>

You see, our injection is reflected two times i the same line. All we have to do now is this:

\">"</script><script>alert(document.domain)-"\

What did we do here? Let me explain: First we break out of the href with \”>. The \ is required as it will escape the ” later in the script context. After that we have another “. This is going to mark the end of our string. Then we have a simple closing script tag. This won’t be recognized as malicious by the auditor as we have no starting script tag before. Now we start our new script with an opening script tag and write our payload after it. We now have to get rid of everything what’s behind our payload, otherwise we’d get a syntax error. We simply do this with a -“\. The ” will mark a new string and the \ will escape the quote that’s left of our payload. This is really hard to describe, so better see for yourself how the payload looks in the end:

multi reflection 1

Some art right here

Again this will alert. [click] Unfortunately this isn’t a common case. When we have multiple reflections they are often separated with newlines and other tags like here:

another injection

This one looks harder, but is in fact easy

We can’t use the trick we just used here. Simply because we have a newline that’s separating our payloads. So what would be a post about filter bypasses without template strings? I can’t even imagine it. As we know they allow multi-line strings which is exactly what we need here. Unfortunately the auditor knows about them and won’t allow them when there’s any character between an opening script tag and a template string. So what can we do about it? It’s really easy:

">`;alert(1)</script><script>`

That way there’s no character between our template string and the script tag and we can enclose everything that would produce a syntax error. To be honest that same payload would also work on the first example of a double injection. Even a ‘ instead of the template string would. But it was a great challenge to try it with double quotes and backslashes. Here is our payload in action: [click]

multiline with `

The ` makes it work in a multiline scenario

All this is possible due to the fact that the auditor searches for the same dangerous string in a the request and response body, trusts local resources, doesn’t consider multi-injections and is not really strict to avoid false positives, which is important for a browser with such a market share. I’m sure there are some other bypasses just waiting to be found.

You can try everything I showed you earlier when using this link:

https://poc.asdizzle.com/auditor-tests/?mode=plain&q=INJECTION

There’s different modes you can try: