Ones and zero code in green with

Cross-site scripting (XSS): what it is and defenses against it

Ones and zero code in green with

How does XSS work? 

Cross-site scripting or XSS occurs when an attacker embeds malicious scripting commands on a trusted website. Websites that have a large amount of inputs are especially vulnerable to this kind of attack since this is how an attacker embeds the script into the website.

There are three types of XSS attacks:

  1. Stored/Persistent XSS

  2. Reflected XSS

  3. DOM-based XSS

Let's give each one of these a closer look!

1. Stored/Persistent XSS

This type of attack is called persistent since they remain on the server. Usually, attackers will target websites that accept user input that stays stored in their database, such as forums, blogs with enabled comments, CRM / ERP Systems, web-based email servers or clients, or any other type of website where users can share their content. 

For example, let's say that I have a forum website where users can write comments about different topics. The attacker might write a comment like this:

“The weather is fantastic today! <script scr=’’>”

Once the attacker submits the comment, it will be stored in the website database and will be rendered for any user that opens the forum page. So, the next time a user opens the page, without them doing anything, the script in that comment will run.

Usually, the attacker will want to steal the user's session cookies. This allows the attacker to compromise the user's account, granting them access to the user's personal information and credit card data. Meanwhile, the visitor, who may never have even scrolled down to the comments section, is not aware that the attack took place.

2. Reflected XSS

This type of attack occurs when an application allows reflected input.

For example, let's say the attacker finds a website where you can search for "XSS" and the website returns (or reflects) a page with the heading "You searched for XSS", followed by the search results.

Instead of just searching "XSS" the attacker might want to search for: "<script scr=’’>", thus, creating a URL like this: "<script scr=’’>".

But this by itself doesn't do any harm since it is not reaching any other users. Unlike with Stored/Persistent XSS, for the Reflected XSS to work, the user needs to click a link from the attacker.f

So, how does the attacker get a user to click their link? Simple, it is just about embedding it in a link and sending it to other users in a seemingly harmless email or blog comment for example, and wait for someone to click. The question is, why would the user do that? Usually, the attacker will use some sort of social engineering (for example, pretexting or phishing) to manipulate the user into taking that action.

Once this link is clicked, the script will run since the website will reflect the search query (which is the malicious script).

3. DOM-based XSS

This type of attack uses the code originating from the website to execute the malicious script.

For example, let's say we have a website with 3 different tabs and it renders different images depending on the tab we click. This whole logic is driven by a script that can be checked in the DOM. So we have these URLs:

"" when we click on the first tab. It renders the image "<img src="cloud1.jpg">"

"" when we click on the second tab. It renders the image "<img src="cloud2.jpg">"

"" when we click on the third tab. It renders the image "<img src="cloud3.jpg">"

By making use of the logic inherent to the website, the attacker can do:'  oneerror='alert()'. This causes an alert to pop up when using the link, and the attacker has just worked around the DOM of the website.

And just like in Reflected XSS, the attacker can embed the link and send it to other users in hopes they will click and the malicious code will run on their end.

How to prevent XSS attacks?

Simply enough there are two things we can do to prevent these kinds of attacks:

1. Input validation.

The best solution is to determine the type of input that the application and create an input validation that matches the input from the user to the type of input we want to allow. If we are expecting the user to input some numbers, we shouldn't allow letters in the input. We can do this in the front-end and the back-end (or in both at the same time), but if we had to choose, it is preferable to do it in the back-end since the attacker won't be able to modify the code of the application itself by normal means.

2. Be careful of the links we click.

Think twice and check URLs before clicking. This is an easy prevention on the user side. To check if a link is malicious, hover on top of the link and the browser will show the URL where this link will direct you. If the URL looks suspicious, double-check with other people in our organization or just write the website we want to go to in the browser.

Long cta
Request a demo cta