appsec xss case study

Security Verified

© 2012 iCode information security All rights reserved

Chapter 04 Cross-Site Scripting

Application Security

Mohamed Ridha Chebbi, CISSP [email protected]

mailto:[email protected]�

Security Verified


Introduction

• Cross-site scripting (or XSS) is the Godfather of attacks against other users.

• It is by some measure the most prevalent web application vulnerability found in the wild.

• there are many situations in which XSS does represent a critical security weakness within an application. It can often be combined with other vulnerabilities to devastating effect.

• In some situations, an XSS attack can be turned into a virus or a self-propagating worm.

Security Verified


Reflected XSS Vulnerabilities

• A very common example of XSS occurs when an application employs a dynamic page to display error messages to users. Typically, the page takes a parameter containing the text of the message, and simply renders this text back to the user within its response.

• This type of mechanism is convenient for developers, because it allows them to invoke a customized error page from anywhere in the application, without needing to hard-code individual messages within the error page itself.

Example of Dynamic URL : https://adb-app.com/error.php?message=Sorry%2c+an+error+occurred

Crafted URL https://adb-app.com/error.php?message=<script>alert(‘xss’);</script>

Security Verified



• This type of simple XSS bug accounts for approximately 75% of the XSS vulnerabilities that exist in real-world web applications.

• It is often referred to as reflected XSS because exploiting the vulnerability involves crafting a request containing embedded JavaScript which is reflected back to any user who makes the request.

Security Verified



Security Verified


Stored XSS Vulnerabilities

• A different category of XSS vulnerability is often referred to as stored cross-site scripting. This version arises when data submitted by one user is stored within the application (typically in a back-end database) and then displayed to other users without being filtered or sanitized appropriately

Security Verified


Storing XSS in Uploaded Files

• If you can upload an HTML or text file containing JavaScript, and a victim views the file, then your payload will normally be executed.

The following shows the raw response of an application that is vulnerable to stored XSS in this way : HTTP/1.1 200 OK Date: Sat, 5 May 2011 11:52:25 GMT Server: Apache Content-Length: 39 Content-Type: image/jpeg <script>alert(document.cookie)</script> Note : Even though the Content-Type header specifies that the message body contains an image, Internet Explorer overrides this and handles the content as HTML because this is what it in fact contains.

Security Verified


DOM-Based XSS Vulnerabilities

Here an example of the the process by which the attacker’s JavaScript gets executed is as follows: ■ A user requests a crafted URL and containing attacker’s JavaScript. ■ The server’s response does not contain the attacker’s script in any form. ■ When the user’s browser processes this response, the script is executed.

How can this series of events occur? The answer is that client-side JavaScript can access the browser’s document object model (DOM), and so can determine the URL used to load the current page. A script issued by the application may extract data from the URL, perform some processing on this data, and then use it to dynamically update the contents of the page. When an application does this, it may be vulnerable to DOM-based XSS.

Security Verified


DOM-Based XSS Vulnerabilities

For example, suppose that the error page returned by the application contains the following: <script> var a = document.URL; a = unescape(a); document.write(a.substring(a.indexOf(“message=”) + 8, a.length)); </script> This script parses the URL to extract the value of the message parameter and simply writes this value into the HTML source code of the page.

Note : if an attacker crafts a URL containing JavaScript then this code will be dynamically written into the page and executed.

Security Verified


Real-World XSS Attacks

AJAX : Ajax (or Asynchronous JavaScript and XML) is a technology used by some applications to create an enhanced interactive experience for users. Ajax is implemented using the XMLHttpRequest object. The following is a simple example of using Ajax within Internet Explorer to issue an asynchronous request and process its response: <script> var request = new ActiveXObject(“Microsoft.XMLHTTP”); request.open(“GET”, “https://wahh-app.com/foo”, false); request.send(); alert(request.responseText); </script> Ajax could be used to trivially violate the browser’s same origin policy, by enabling applications to retrieve and process data from a different domain.

Security Verified


Payloads for XSS Attacks

• Virtual Defacement

• Injecting Trojan Functionality

• Inducing User Actions hijacking a victim’s session

Security Verified


Payloads for XSS Attacks

• Exploiting Any Trust Relationships There are several trust relationships that can sometimes be exploited in an XSS attack: ■ If the application employs forms with autocomplete enabled, JavaScript issued by the application can capture any previously entered data that the user’s browser has stored in the autocomplete cache. ■ Some web applications recommend or require that users add their domain name to the “Trusted Sites” zone of their browser. This is almost always undesirable. For example, injecting the following code will cause the Windows calculator program to launch on the user’s computer: <script> var o = new ActiveXObject(‘WScript.shell’); o.Run(‘calc.exe’); </script> ■ etc.

Security Verified


Escalating the Client-Side Attack

• Log Keystrokes

<script>

document.onkeypress = function () {

window.status += String.fromCharCode(window.event.keyCode);

}

</script>

• Capture Clipboard Contents

<script>

alert(window.clipboardData.getData(‘Text’));

</script>

• Steal History and Search Queries

JavaScript can be used to perform a brute-force exercise to discover thirdparty sites recently visited by the user (using getComputedStyle API)

• Enumerate Currently Used Applications

JavaScript can be used to determine whether the user is presently logged in to third-party web applications. The trick is to attempt to dynamically load and execute the protected page as a piece of JavaScript:

window.onerror = fingerprint;

<script src=”https://other-app.com/MyDetails.aspx”></script>

Security Verified


Escalating the Client-Side Attack

• Port Scan the Local Network

JavaScript can be used to perform a port scan of hosts on the user’s local network

• Attack Other Network Hosts

The following code checks for a specific image associated with a popular range of DSL routers:

<img src=”http://192.168.1.1/hm_icon.gif” onerror=”notNetgear()“>

Security Verified


Preventing Reflected and Stored XSS

■ Validate input. ■ Validate output. ■ Eliminate dangerous insertion points.

Security Verified


Validate Input

The application should perform context-dependent validation of input data, in as strict a manner as possible. Potential features to validate include the following: ■ That the data is not too long. ■ That the data only contains a certain permitted set of characters. ■ That the data matches a particular regular expression. Different validation rules should be applied as restrictively as possible to names, email addresses, account numbers, and so on, according to the type of data that the application is expecting to receive in each field.

Security Verified


Validate Output

Output data should be HTMLencoded to sanitize potentially malicious characters. HTML-encoding involves replacing literal characters with their corresponding HTML entities. This ensures that browsers will handle potentially malicious characters in a safe way, treating them as part of the content of the HTML document and not part of its structure. The HTML-encodings of the primary problematic characters are as follows: “ " ‘ ' & & < < > >

In addition to these common encodings, in fact any character can be HTMLencoded using its numeric ASCII character code, as follows: % % * *

Security Verified


HTML Encoding Example

On the Java platform, there is no equivalent built-in API available; however, it is simple to construct your own equivalent method using just the numeric form of encoding. For example: public static String HTMLEncode(String s) { StringBuffer out = new StringBuffer(); for (int i = 0; i < s.length(); i++) { char c = s.charAt(i); if(c > 0x7f || c==’“‘ || c==’&‘ || c==’<’ || c==’>’) out.append(“&#“ + (int) c + “;”); else out.append(c); } return out.toString(); }

Security Verified


Eliminate Dangerous Insertion Points

Inserting user-controllable data directly into existing JavaScript should be avoided wherever possible. When applications attempt to do this safely, it is frequently possible to bypass their defensive filters.

A second location where user input should not be inserted is any other context in which JavaScript commands may appear directly. For example: <img src=”userdata”> <img src=”foo.gif” onload=”userdata”>

In this case an attacker can proceed directly to injecting JavaScript commands within the quoted string. For example: <img src=”javascript:alert(document.cookie)“> <img src=”foo.gif” onload=”alert('xss')“>

Security Verified


Preventing DOM-Based XSS

• Validate Input

• Validate Output

Security Verified


Validate Input

In many situations, applications can perform rigorous validation on the data being processed. Indeed, this is one area where client-side validation can be more effective than server-side validation. Validating that the data about to be inserted into the document only contains alphanumeric characters and whitespace could be for example: <script> var a = document.URL; a = a.substring(a.indexOf(“message=”) + 8, a.length); a = unescape(a); var regex=/^([A-Za-z0-9+\s])*$/; if (regex.test(a)) document.write(a); </script>

Security Verified


Validate Output

As with reflected XSS flaws, applications can perform HTML-encoding of user-controllable DOM data before this is inserted into the document. This will enable all kinds of potentially dangerous characters and expressions to be displayed within the page in a safe way. HTML encoding can be implemented in client-side JavaScript with a function like the following: function sanitize(str) { var d = document.createElement(‘div’); d.appendChild(document.createTextNode(str)); return d.innerHTML; }

Security Verified


Thanks

Mohamed Ridha Chebbi, CISSP

appsec xss case study

Technology