Top Three Cross-Site Scripting Attacks You Need to Know Now

Cross-Site Scripting or XSS is and will remain to be a major pain for anyone trying to create a secure web application for their end-users.

Cross-Site scripting attacks occur when an attacker can squeeze nasty code into your web application from any input field or functionality where a user can have their input reflected in the source code of your application.

The primary issue usually always falls down to sanitizing user input, in other words; it is essential to check the data going into the web application and also where it shows or how it is handled in the output from the site. Easier said than done!

A basic concept

Let's say you post a comment online like Hello World.. (a cliche example). The web application will then show the text for everyone to see…. If this web application was vulnerable to a cross–site scripting attack then we could inject code into the application!

If an attacker can inject code similar to this on your site, they can do all kinds of malicious activity!

There are a few types of Cross-site scripting and we will have look at the most common three.

Types Of Cross Site Scripting

Reflected:

Reflected injections are inserted in a URL link that an attacker wants a victim to click!

First of all, we shall look at reflected Cross-Site Scripting occurs when the data is passed in a parameter in the URL.

HTTPS://www. google.com/ *notreal?ThisIsAParameter=IamTheValue*

The Injection would be passed in the value of this link and if an attacker loaded this with malicious script and victims began clicking it, they could exploit various attacks, such as… Stealing Cookies to take over accounts or stick a java-script keylogger on the site...

Reflected attacks only work when the URL is sent to someone – although if we were lucky in testing we'd find the next kind of XSS…

Stored:

These injections are stored on the server… like a Facebook or Twitter post, its there for the long-haul! This is as bad as it can get.

So once we find an XSS hole that lets us store our injections on the server, things get a little more interesting.

The attack surface of the exploit greatly raises. We no longer need to click the link in the previous example. Instead just by visiting the page where the injection is stored, it will fire.

As before we could steal cookies etc. but also start altering the entire web page layout for good.

Dom:

Lastly is Dom. This XSS injection is a tricky one. It can be hard to find, hard to exploit and even for me it can be hard to explain. In this attack surface, we are feeding data into already existing Java-script to create an exploit. A short snippet from the OWASP guide states:

"DOM Based XSS is an XSS attack wherein the attack payload is executed as a result of modifying the DOM "environment" in the victim's browser used by the original client side script, so that the client sidecode runs in an 'unexpected' manner."

So we have given some basics on the types of XSS…

As an attacker we need to know the landing spaces of the data, then we can start to craft attacks and by-passing filters!

Landing spaces for Cross–Site Scripting

There are four landing spaces for XSS

In White space
Attribute space
URI (Uniform Resource Identifier)
Script space

- White space / Text space

This is when the user input lands in clear space.

If your injection lands here in the source this would be White space

Therefore, White space injections need to open tags '<>' to create HTML and apply events or to directly open script tags for an exploit.

- Attribute space

If your input lands inside an Event Attribute then we can craft a different stlye injection but achieve the same results!

The 'on' attributes like, onerror, onload, onmouseover etc can involve Java-script and as such provide room for an attack. We have cleverly closed out the value attribute with our double quote. This allows us to create a new event handler, onclick, and give it some script to run. Even more so, we can create these attribute space exploits in the previous example.

NOTE: The asterisks above will break our injection, there are there to outline the specific landing spot!

- URL

More Acronyms.. URL Universal Resource Location
A URL is a basic web address: http://www.google.com
Landing in a URI spot is common enough and also gives a variety of injections to work with.

< a *href=javascript:alert()>Click Me!* < / a >

Here we have set the HREF attribute to some basic java-script to show your cookies for the current web page. If our supplied data lands at the beginning of the HREF= value, then a world of possibilities opens up. The ability to execute javascript above is a great place to start in exploiting XSS.

Additional and more complex injections in this landing space become available to us, like the following:

< *a href=data:html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==* >

This example is using the data URI and then specifying the media type 'html' and then the encoding 'base64' followed by the encoded JavaScript. This is a small glimpse into how we can create complex injections to bypass filters.

- Script Space

Script space injections are my personal favourite. When our data lands inside script tags our main objective is to add additional Javascript, without breaking the syntax of the code around us. Sometimes this is extremely straightforward, other times it can be hours of restructuring code to flow with the script around us. These injections can come to be a plethora of quotes, parenthesis, braces and functions.

In previous landing spaces above, we addressed the concept that we can close out html tags and create our new code on the fly. Script space injections are no different than this. Additionally, this is the only instance where we do not need to worry about the previous syntax of the landing space as we do not care if it runs or fails. Although, landing in script space and having the ability to close out the code with a simple tag is not so common. Therefore we need to start assessing which special characters we can work into the landing space. () `` {} ; //[] The more special characters we can get in, the more we have to work with, and in-turn have a great chance of getting a working exploit!

This has been a brief cover of XSS… Soon I will address the other concepts in this field such as encoding types, such as URL, HTML, BASE64 etc. for special characters and also various browsers and how each can handle or interpret injections differently to increase our attack surface.

About the author: Jonny Rice works as a vulnerability web application specialist for leading application security provider WhiteHat Security.