What XSS attacks doesn't "Reflective XSS Protection" defeat?

Question

Its been quite a while since I have played with cross site scripting vulnerabilities but today I came across a website today that was crying out to be tested for a basic XSS vulnerability.

So dutifully I typed in:

http://example.com?query=<script>alert('hey!')</script>

And was quite surpised when I wasn't met with an alert box showing the message 'hey!'.

I checked the source and could see the code was clearly being injected and when I tried something more simple such as:

http://example.com?query=<h1>hey!</h1>

It injected the HTML as expected.

This is when I checked my error log and saw this message (in Chrome):

Refused to execute a JavaScript script. Source code of script found within request

After a bit of investigation I found that this is a feature called "Reflective XSS Protection " that was introduced in to webkit. If code is seen in both the query and the body then it won't be executed.

So my question: When I've played around with cross site scripting in the past this is basically how I've done it. Does this effectively wipe out a great deal of XSS attacks or just the primitive ones?

Answer 1

There are three major types of XSS:

• Reflected XSS
• Stored XSS (aka persistent XSS)
• Dom-based XSS (aka client-side XSS)

Reflective XSS protection only protects against the first, but does not protect against stored XSS or Dom-based XSS.

Also, reflective XSS protection can often be bypassed. It does not protect against all reflected XSS attacks. It's a mitigation, not a strong defense. Therefore, you shouldn't rely upon it for security: you still need to fix every XSS vulnerability you find.

Answer 2

https://bugs.webkit.org/buglist.cgi?keywords=XSSAuditor&resolution=--- Are for sure ways for bypassing the filter. (Taken from the blog site).

There are always ways to obfuscate code - Check out https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet for a long list of evasion possibilities.

Answer 3

First of all it is not implemented in all browsers, so only some users will be protected against some XSS attacks. For sure as the time will go, more vendors will adopt such strategy, but there will be plenty of users who use outdated software (and this is the type of vulnerability an attacker is looking for).

Moreover even in the blog article it is stated that :

We are aware of a few ways to bypass the filter,

and for sure people will find more possibilities. As it stated in the blog, it can deal with a lot of XSS types of attack, not just a primitive ones.

So in my opinion it will just force real attackers to experiment more with XSS and make a learning curve harder for script kiddies

Thinking about it a little bit further I want to add that in my opinion this can cause harm as well. Look at it from this perspective: some developers can fall into a wrong conclusion that if a browser already to all the job for XSS prevention, why should I bother doing anything. Ordinary devs might become less aware of XSS and when someone find a way to block this feature in the browser, the problems will arise.

P.S thanks for an interesting post

Answer 4

Well in addition to the potential bypasses of the protection as mentioned in the other answers, the obvious section is where the XSS vector isn't immediately returned in the same browser window, which includes most stored XSS vulnerabilities.

So as an example, where an XSS vector is entered by a user (for example a comments box) and that is later displayed in an administrative interface, the admins browser would have no effective way of knowing that the script had come from a user rather than being part of the site functionality.