Search code examples
javascripthttphttp-headersxssfiddler

Reflective XSS Protection - clarification?

After reading this article by Eric Lawrence ,I saw this test page http://www.enhanceie.com/test/xss/ which simulates the usage of Reflective XSS Protection.

Now , According to google chromium :

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.

So , If I post to the server : 

<script>alert("bang! script injection\n"+document.cookie);</script>

And the browser also sees it at the request via url: 

http://webdbg.com/test/xss/Hello.asp?txtName=%3Cscript%3Ealert%28%22bang%21+script+injection%5Cn%22%2Bdocument.cookie%29%3B%3C%2Fscript%3E

then it shows this error ( console):

The XSS Auditor refused to execute a script in 'http://webdbg.com/test/xss/Hello.asp?txtName=%3Cscript%3Ealert%28%22bang%21+script+injection%5Cn%22%2Bdocument.cookie%29%3B%3C%2Fscript%3E' because its source code was found within the request. The auditor was enabled as the server sent neither an 'X-XSS-Protection' nor 'Content-Security-Policy' header.

But fiddler does show me that the page did get the script to run :

enter image description here

Question :

As the solution to deal with xss is html Encode/decode ,

How/when should I combine between those 2 solutions ?

I mean I could use html encode and scripts would never run in my page , or , I could use this header... ?

Im confused.

Solution

  • But fiddler does show me that the page did get the script to run

    No, it doesn't. Fiddler shows you that the server sent the script back to the browser. It tells you absolutely nothing about what the browser did with the script.

    As the solution to deal with xss is html Encode/decode

    That is one solution (also the simplest and best if you don't need to allow users to submit any kind of HTML).

    How/when should I combine between those 2 solutions?

    You should encode any user input you get as HTML by encoding entities, and ignore anti-XSS filters that appear in some browsers because not all browsers have them so you cannot depend upon them.

    I mean I could use html encode and scripts would never run in my page

    Only encode user input (because it is untrusted). Don't encode scripts you write yourself and therefore can trust.