This third article of our series dedicated to understanding web vulnerabilities in 5 min is focused on Cross Site Scripting (also known as XSS).

XSS flaws are really widespread on the Internet, and used for many website attacks today. Even if that vulnerability has been pointed out by security experts for years, we still find lot of them in web applications. The reason why is that a) it’s very easy to develop code that is vulnerable to that attack, and b) it’s quite painful to fix.
The impact of such vulnerabilities is quite important when exploited. It can lead to session hijack (please refer to the previous article of the series for more info), website defacement, hostile code injected in your webpages, malware injection…

To make it simple, there are 3 sub-types of XSS attacks: stored XSS attacks, reflected XSS attacks and DOM based XSS attacks. We’ll try to explain them in simple terms.

These 3 subtypes of attacks use “malicious contents”. By malicious, content, you should understand content that will be rendered on the victim’s browser in a non-expected way.
One very simple example of this is the display of a popup with a message that the victim will see on his device, or a redirection to another website (generally malicious).
We will not detail all the possible consequences of XSS attacks, they are uncountable and sometimes hard to explain. Just consider that an attacker can basically make anything the victim can do with is browser when the flaw is exploited.

Phishing attack illustration
Phishing attack

1. Stored XSS attacks:

This one is quite easy to understand.
An attacker sends a malicious content to the web application,  which in turn records the data (for instance in a database). Then, the malicious content is returned to all other users on the website.
As an example, let’s consider a forum, or a blog. The attacker will post a new message or comment, containing malicious data. When other users will then visit the forum or the blog, the malicious content will be there, every time they display the page.

This first type of XSS attack is called “stored” because the malicious content is recorded on the server and then always returned to the victims.

 

2. Reflected XSS attacks:

This second type of XSS does not store malicious content on the web server. The malicious content can be for instance delivered to the client through a URL (sent in an email or by any other way):
Imagine a website where you can see the weather forecast for a given town. The name of the town can be provided in the URL of the page like this:
www.victim-website-example.com/weatherforcast?town=Lyon

The page would then show you the weather in Lyon, reusing the town name you provided in the URL to display “Here is the the weather in Lyon:”.
The attacker would use that URL to send malicious code like this: www.victim-website-example.com/weatherforcast?town=Lyon[malicious code]

With this malicious content in the URL, the web server will then maybe display the weather forecast for Paris, but also include the malicious content in the page. The attack is finished.

 

3. DOM based XSS attacks:

That one is a bit more tricky and hard to explain.
The first characteristic of this third subtype of XSS attack is that it does not use the server. In the two previous types, the data was first sent to the server, then rendered on the victim’s browser.
In DOM XSS, everything takes place in the browser of the victim:

The ability for the web browser to run code (like javascript code) is sufficient for XSS. (But it is not limited to Javascript)
This type of attack is prevalent in “web 2.0” applications, where a lot of javascript code is executed in the browser without necessarily interacting with the server.

Let’s take an example.
Suppose you have a website where you can find anagrams of a given word. Such application can be fully developed in Javascript and would not need any interaction with the server: all the anagrams of the word you provide can be computed directly by your web browser, in Javascript.
If you display the following URL: www.victim-website-example.com/anagram_app/input/myword , the page would then display the anagram of “myword”.
An attacker would send you to the following URL: www.victim-website-example.com/anagram_app/input/myword[malicious code]
The anagram application would then interpret the malicious code, and if the attacker “did his job well”, the application would behave in a non-expected manner, allowing for many kind of consequences, like stealing your cookies, redirecting you to another website.

 

How can we prevent such attacks?

Whichever type of XSS attack you are considering, all of these attacks are based on the fact that the content received by the web application from the outside cannot be trusted. Developers must follow strict rules to properly handle data coming from the outside, whether it’s from a URL or from the different forms made available on the different pages.
For Reflected and Stored XSS, any content provided by the user must be “escaped” (cleaned), “validated” so that whatever it contains it can then be safely returned to the user on the page.
For DOM based XSS, the content must also be encoded before being used in the client application.

Automated security tools can detect some of the XSS flaws, but a manual penetration testing or code review can handle more of them.

Learn more about XSS:

OWASP XSS article
OWASP DOM XSS article

Other articles in this series: