Multifaceted Tests : Making HTTP Requests Using XSS & Attempting DOM-Based XSS Interactively

12/20/2011 5:32:51 PM

1. Making HTTP Requests Using XSS

1.1. Problem

One of the most powerful tools available to an attacker building an XSS exploit is being able to generate requests to the target website from the victim’s browser and being able to read the responses. This recipe will discuss how you can use JavaScript to make requests to the target website from the victim’s browser.

1.2. Solution

Create a JavaScript file containing the script in Example 1 and make it accessible at (wherever your attack server is), and then insert it into the vulnerable page using the technique described in Example 3.

Example 1. JavaScript for making HTTP request
var xmlhttpreq;

/* Most browsers use a XMLHttpRequest object for making
AJAX Requests */
xmlhttpreq=new XMLHttpRequest();
else if(window.ActiveXObject){
/* Internet Explorer uses ActiveXObject for making
AJAX Requests */
xmlhttpreq=new ActiveXObject("Microsoft.XMLHTTP");

if (window.XMLHttpRequest) {
} else {

/* The server's response is stored in the variable 'response' */
var response = xmlhttpreq.responseText;

1.3. Discussion

Example 1 will submit a request to the target website from the victim’s browser, and the response will be stored in the variable response where it can be parsed using JavaScript and the information contained in it can either be sent to the attacker as in the previous two recipes or used in subsequent requests made to the target website. For example, if an attacker finds an XSS vulnerability in an online banking website, the attacker could write JavaScript code to submit a request to the site, parse the account numbers from the response, and use them to initiate a transfer to the attacker’s bank account.

This attack works because the victim’s browser submits the user’s session cookie to the vulnerable website along with each request to the website. The vulnerable website authenticates each request by verifying the user’s session cookie and cannot differentiate between requests initiated by the legitimate user and requests generated using the attacker’s JavaScript code.

This attack only works when the target website is vulnerable to XSS. Although it is possible to submit requests to any website via CSRF attacks , reading the server’s responses and leveraging the information in the responses is only possible when the target is vulnerable to XSS. This is because web browsers enforce a “same origin policy”[8] that only allows AJAX requests to be made to the website that the user is visiting. Using this technique, the attacker’s script can mimic any actions that the legitimate user can perform.

2. Attempting DOM-Based XSS Interactively

2.1. Problem

DOM-based cross-site scripting involves client-side JavaScript code outputting untrusted data without filtering or encoding. It is very important for testers to be aware of this type of cross-site scripting because many traditional methods of finding XSS vulnerabilities do not detect certain types of DOM-based XSS.

2.2. Solution

To test for DOM-based cross-site scripting, it is best to use Internet Explorer.

There is another important test for DOM-based XSS. When you suspect that parts of the URL are being handled by client-side JavaScript code and are being output to the user, inject XSS test strings into those parts of the URL. For instance, if URL fragments are used to filter information to be displayed to the user, and the fragment value is displayed to the user, then a URL such as the one shown in Example 2 will demonstrate a DOM-based XSS issue.

Example 2. Sample test input for finding DOM-based XSS<script>alert('XSS')</script>

As with other similar XSS tests, the application fails (i.e., is vulnerable) if you see an alert box.

2.3. Discussion

These involve sending malicious data to a vulnerable server that then either reflects it back to the browser immediately or stores it somewhere where it is retrieved later. Although DOM-based XSS is not as common as the other two types of XSS yet, it is an additional type of XSS that needs to be tested for.

DOM-based XSS is fundamentally different from reflected XSS and stored XSS because it does not require client-server interaction. The vulnerability occurs when client-side JavaScript handles user input and displays it to the user without encoding or filtering. The systematic methods of finding cross-site scripting do not detect DOM-based XSS because they check the server’s response for the injected strings, but in this case, the server-side code may not necessarily be vulnerable to XSS.

Example 3 shows a somewhat unrealistic JavaScript function that is vulnerable to DOM-based cross-site scripting.

Example 3. Example of DOM-based XSS vulnerability
function displayFragment() {
Fragment = document.createElement("div");
Fragment.innerHTML = "<h2>" + location.hash.substring(1) + "</h2>";
/* ... */

Here, location.hash returns the fragment identifier in the URL (plus the # symbol). The substring(1) strips off the first character. Thus, if the attacker crafts a link such as the one shown in Example 4, the attacker’s script will be executed by the victim’s browser, and there will be no indication of an attack on the server side.

Example 4. Sample URL for exploiting DOM-based XSS<script src=''></script>

Testing for DOM-based XSS requires dynamic analysis of client-side JavaScript, and one way to perform this is by interactive testing using a web browser. It is best to use Internet Explorer for this testing because some browsers such as Mozilla Firefox automatically encode characters such as < and > in URLs to %3C and %3E. Thus, unless the JavaScript performs URL decoding, the exploit may not work in such browsers.

Note that the typical interactive methods of finding XSS issues can also find some DOM-based XSS issues. With DOM-based cross-site scripting, it is important to test input that may only be handled on the client side (e.g., URL fragments). Testing only the client-server interaction is insufficient.

DOM-based XSS is one reason why application firewalls and intrusion detection systems are not completely effective at protecting applications from XSS issues.Most browsers do not send URL fragments to the server. In this example, the server would only see a request for and there will be no evidence of attack on the server side.
  •  Multifaceted Tests : Stealing Cookies Using XSS & Creating Overlays Using XSS
  •  IIS 7.0 : Securing Configuration - Controlling Configuration Delegation
  •  IIS 7.0 : Securing Configuration - Securing Sensitive Configuration
  •  IIS 7.0 : Securing Configuration - Restricting Access to Configuration
  •  Web Security Testing : Changing Sessions to Evade Restrictions & Impersonating Another User
  •  Web Security Testing : Manipulating Sessions - Analyzing Session Randomness with WebScarab
  •  Web Security Testing : Manipulating Sessions - Analyzing Session Identifiers with Burp
  •  Programming .NET Security : Extending the .NET Framework (part 2) - Defining the Key Exchange Deformatter
  •  Programming .NET Security : Extending the .NET Framework (part 1) - Defining the Key Exchange Formatter
  •  Programming .NET Security : Programming Cryptographic Keys (part 3) - Key Exchange Formatting
    Video tutorials
    - How To Install Windows 8

    - How To Install Windows Server 2012

    - How To Install Windows Server 2012 On VirtualBox

    - How To Disable Windows 8 Metro UI

    - How To Install Windows Store Apps From Windows 8 Classic Desktop

    - How To Disable Windows Update in Windows 8

    - How To Disable Windows 8 Metro UI

    - How To Add Widgets To Windows 8 Lock Screen

    - How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010
    programming4us programming4us