Cross Site Scripting (XSS): What Is It & What’s an Example?

In 2018, British Airways reported a data breach that affected 380,000 booking transactions between August and September. The breach was possible due to a cross-site scripting vulnerability.

This type of vulnerability enabled a hacker group known as “Magecart'' to inject a malicious JavaScript library into an unsecured payment form on British Airways’ website so that when users submitted the form, their credit card details and other personal data was recorded and sent to a server that the attackers controlled. The vulnerability was caught and later patched, but the company was still fined over 220 million US dollars for failure to comply with GDPR.

To avoid such an attack on your site and to protect your users’ data, you have to first understand what cross site scripting is and what makes your site vulnerable to this type of attack. Let’s take a closer look below.

cm

What is cross site scripting?

Cross site scripting, often shortened to XSS, is a type of attack in which a user injects malicious code into an otherwise legitimate and trustworthy website or application in order to execute that malicious code in another user’s web browser. Because that browser thinks the code is coming from a trusted source, it will execute the code.

The goal of the attacker might be to gain access to a user’s data, like any cookies or session tokens retained by the browser, to masquerade as the user in order to carry out certain actions in the application, or to redirect the user to a harmful website that they control.

Here’s an illustration of cross site scripting:

Image Source

Let’s take a look at another example below.

Cross Site Scripting Example

Let’s use an example based on a real XSS attack that affected eBay in 2014.

Say a perpetrator discovers a vulnerability on an ecommerce site that allows them to insert malicious Javascript code within specific product listing pages. Now, when customers click on a compromised listing, they will be automatically redirected to a page asking them to login. If they do log in, then the perpetrator will have their account username and password. With this information, they’d have easy access to customers’ personal information, including their credit card data.

This is an example of a reflected attack, which we’ll discuss in more detail below.

Cross Site Scripting Vulnerability

The major cross site scripting vulnerability is untrusted user data. Untrusted user data most commonly comes from the HTTP request and takes on the form of URL parameters, form fields, headers, or cookies. Untrusted data may also come from search fields, databases, web services, and other sources. This input is considered “untrusted” because it can be manipulated to contain a malicious script.

A web application is vulnerable to cross site scripting attacks if it:

• stores user input without sanitizing, validating, or encoding it
• dynamically includes user data in its HTTP responses without sanitizing or validating it

Because of these vulnerabilities, an attacker could inject malicious code into a website or application through a simple HTTP request, for example. Then this malicious code could be included in requested or dynamic content and sent back to an end user, where it would be executed on their browser.

Types of Cross Site Scripting Attacks

Cross site scripting attacks can be categorized in three ways: reflected, stored, and DOM Based attacks. Stored and reflected attacks are more well-known but we will discuss all three types below.

Stored Cross Site Scripting

Stored cross site scripting — also known as Persistent or Type-I cross site scripting — refers to attacks in which the malicious script is permanently stored on the target servers. It might be stored in a database, message forum, visitor log, or comment field, for example.

A user that requests the stored information from the server will also retrieve the malicious script and become a victim of this type of XSS attack.

Reflected Cross Site Scripting

Reflected cross site scripting — also known as Non-Persistent or Type-II cross site scripting — refers to attacks in which the malicious script is “reflected” off the target servers. That means the malicious script could be part of an error page, search result, or another response to a request sent to the target server.

When a user interacts with this malicious script by, for example, clicking on a link in an email, submitting a form, or browsing a web page, then the script travels to the compromised website and reflects the attack back to the user’s browser. Meaning, the user’s browser accepts and executes the malicious script from the website because it trusts its server.

So the key difference between stored and reflected XSS is the source of the malicious script that is included in an HTTP response generated by the server. The source of the script in stored XSS is a stored location. The source of the script in reflected XSS is the request.

DOM Based Cross Site Scripting

DOM Based cross site scripting — also known as Type-0 cross site scripting — refers to attacks in which the malicious script modifies the DOM environment in the user’s browser and causes the client-side code contained in the web page to execute differently.

So the key difference between DOM based XSS attacks and stored and reflected XSS attacks is that the source of the malicious script is the client, not the server. That’s why DOM based cross site scripting is considered a subset of client XSS, whereas stored and reflected cross site scripting is considered server XSS.

Preventing cross site scripting attacks will involve a combination of best practices and tools. For detailed instructions, check out OWASP’s Cross Site Scripting Prevention Cheat Sheet.

XSS Attacks

Cross site scripting attacks can have a severe technical and business impact that may result in the loss of customer trust and revenue. Understanding what cross site scripting is and what makes your web application vulnerable to them is an important starting point to prevention.