Appsec XSS Case Study

Application Security Security Verified

Chapter 04
Cross-Site Scripting

Mohamed Ridha Chebbi, CISSP
Ridha.chebbi@icodesecurity.com

© 2012 iCode information security All rights reserved

Introduction Security Verified

• 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.


Reflected XSS Vulnerabilities Security Verified

• 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>


• 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.


Stored XSS Vulnerabilities Security Verified

• 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


Storing XSS in Uploaded Files Security Verified

• 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.


DOM-Based XSS Vulnerabilities Security Verified

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.


DOM-Based XSS Vulnerabilities Security Verified

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.


Real-World XSS Attacks Security Verified

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.


Payloads for XSS Attacks Security Verified

• Virtual Defacement

• Injecting Trojan Functionality

• Inducing User Actions
hijacking a victim’s session


Payloads for XSS Attacks Security Verified

• 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.


Escalating the Client-Side Attack Security Verified

• 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>


Escalating the Client-Side Attack Security Verified

• 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()“>


Preventing Reflected and Stored XSS Security Verified

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


Validate Input Security Verified

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.


Validate Output Security Verified

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:
% %
* *


HTML Encoding Example Security Verified

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();
}


Eliminate Dangerous Insertion Points Security Verified

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')“>


Preventing DOM-Based XSS Security Verified

• Validate Input
• Validate Output


Validate Input Security Verified

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>


Validate Output
Security Verified

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

More Related Content

What's hot

Similar to Appsec XSS Case Study

Recently uploaded

Appsec XSS Case Study