Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
And of course I have notified the owner of the website of the issue! :) –  Andy Smith Nov 16 '12 at 13:03
    
"So what I guess what I'm really interested to know is are there any evasion techniques that mean that by design reflective XSS protection won't work?" AndySmith - maybe you should phrase your question that way then. –  user857990 Nov 19 '12 at 7:47
add comment

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
So what I guess what I'm really interested to know is are there any evasion techniques that mean that by design reflective XSS protection won't work? Is it just going to be a game of catch up forever or has someone found a really tricky evasion mechanism that webkit could not block for x reason –  Andy Smith Nov 16 '12 at 16:10
    
There is a finite anount of characters, so if one considers all possibilities, you could escape all. That is not design but implementation though. But there is ongoing research in this field. If therr would've been an easy design change or possibility we wouldn't be facing this amount of xss on the net. For right now it depends on the quality of the implementation. –  user857990 Nov 16 '12 at 21:21
add comment

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

share|improve this answer
    
So are there any examples of such bypasses? Is there such a bypass that for some technical reason cannot be blocked? Or can all be eventually blocked? –  Andy Smith Nov 16 '12 at 15:06
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.