Friday, August 16, 2013

Reflected XSS revisited



XSS (Cross Site Scripting) is a server vulnerability and the victim is the client's web browser. It consists on injecting  a malicious script code (generally JavaScript) into the web browser. The injected script will be executed in the context of the vulnerable web server, Same Origin Policy (SOP) is, therefore, bypassed, and the script has access to client's confidential data (cookie,online banking informations...).

There are three types of this vulnerability: stored XSS, reflected XSS and DOM-based XSS

Reflected XSS occurs when a web server reflects back a malicious script, injected in the request, to the client's web browser.
The chronology of this attack is as fellow
  1. The victim access the vulnerable web server (www.vulnerable.com) and provide its
      credentials for authentication,
  2. the web server authenticates the victim and sets a cookie for her session,
  3. a hacker sends the victim an Email asking her to click on a forged URL with malicious
      parameters,
  4. the victim clicks on the link,
  5. the server reflects back the malicious script which is executed by the browser,


Figure 1: Reflected XSS attack chronology


Example 1: The web server is vulnerable to reflected XSS
Suppose the following request is sent to a vulnerable web site
       http://www.vulnerable.com/<script>alert("hello world")</script> 
Of course the server will respond with a 404 page not found. The vulnerable web server will include the name of the requested webpage (a malicious script) in the error message (see bellow). The script will, then, be executed by the web browser.
     The requested URL /<script>alert("hello world")</script> was not found on this server 

The best way to defeat this is

  • Sanitizing the special  characters included in the server's error messages, this way the script will be interpreted as a text  by the browser. This is the default behavior of Apache web server. As we  can     see bellow, Apache replaces < with &lt; , > with &gt; and " with &quot;

                                                    Figure 2: Apache 404 error message source code   
 OR

  • Do not include requested page's name in the server's error messages.This is the default behavior of Microsoft IIS
Figure 3: IIS 404 error message

Also, it is worth to note that, by default, Internet Explorer replaces received error messages with it own, this is called friendly error messages
Figure 4: IE friendly error message option

Example 2: The web application is vulnerable to reflected XSS
This example is taken from xssed.com an online archive of XSS vulnerable websites . The script is embedded in a search string.
   http://www.industrie.gov.tn/marquage-ce/www/fr/recherche.asp?cles=<BODY
  ONLOAD=alert("By-Hedi-Mlika")>

As we can see,from the source code, the website reflects back the search string with no special characters sanitization.


The script,which fires an alert box is executed!



How to protect
The protection mechanisms can be implemented on the server side and/or the client side.
On the server side the reflected strings should always be sanitized.
On the client side many web browsers implements XSS filter which is a built-in feature in Internet Explorer and Google Chrome (called XSSAuditor), while it is provided as an extension (NoScript
add-on ) in Firefox.
Bellow is a brief comparison between those three filters. more details can be found in this research
paper.

  • NoScript uses regular expressions to identify  the presence of JavaScript code in HTTP request parameters and sanitizes them before submitting the request.
  • IE XSS filter works differently, it monitors both the request and response, it sanitize  a script code detected in the response if it matches  the one detected in the request. It uses regular expressions for detecting scripts
    IE filter is implemented before the HTML parser. This design permits only a syntax analysis of the response not its semantic, this lowers the precision of the filter


Figure 5: IE8 XSS filter architecture


  • Chrome XSSAuditor: uses a same approach as IE filter. If a matching script is detected, its execution is skipped. XSSAuditor is implemented between HTML parser and JavaScript engine.This is a more efficient design as the filter can examine the semantics of the response as interpreted by the parser

Figure 6: Chrome XSSAuditor Architecture

Moreover, it should be noted that IE's and Chrome's XSS filters can be deactivated by the server by setting the HTTP header X-XSS-Protection to 0.


    

No comments:

Post a Comment