What is cross-site scripting (XSS)?
How XSS exploits work and how to defend against them
Cross-site scripting (XSS) is a client-side variant of the injection attack, which attempts to trick a website into placing malicious code onto a visitor's browser.
XSS attacks target vulnerable websites by having them quietly 'inject' malicious scripts onto a user's machine as they visit the site, enabling the attacker to masquerade as the victim. Any data associated with that user's browser can be accessed by the attacker, allowing them to perform the same website actions and potentially gain access to highly sensitive data.
How it works
The vulnerability allows attackers to bypass the Same Origin Policy (SOP) - a basic principle of web design that prevents applications from accessing the content on pages from a different origin. Typically, the policy ensures websites operate with guardrails, stopping code from that one random online marketplace you visited from accessing code on your online banking dashboard.
For example, under SOP, https://www.itpro.co.uk/index.html can access scripts from the same root address, such as https://www.itpro.co.uk/example.html, but not from https://www.facebook.com/example.html.
However, hackers are able to bypass this restriction by using a cross-site scripting vulnerability to inject their own code onto a website, making it look like that malicious code originated from the attacked website, rather than an external source.
Importantly, this vulnerability only exists on sites that present unsanitised user information as an output on their pages. This is effectively any site that hosts and stores comments, posts, form entries or any other method user input, without performing any additional processing steps before it's hosted, such as stripping away HTML code.
A visitor's browser will treat the malicious code on the site's page as legitimate source code and execute the script automatically, although the exact method of execution can vary depending on the style of attack.
Impact of a successful XSS exploit
Cookie theft has become the most common way of exploiting XSS, especially as the vulnerability gives hackers access to session tokens. Once these are copied over from a victim's browser to their own, a hacker can impersonate the user to perform actions on their behalf, including accessing any sensitive data associated with an online account, or altering credentials to take over the account entirely.
If the affected user has elevated privileges, such as admin rights to a website, the hacker could even launch additional attacks on the server itself, as was the case with the XSS and brute force attacks on Apache.org infrastructure in 2010.
However, this is all dependent on the user being logged into their account at the time of the cookie theft and will not work if other authentication steps are required to maintain access, such as a machine's IP address.
This is all in addition to a hacker being able to view and record data associated with a user's account, including financial data and highly sensitive personal information.
Given that XSS exploits could allow a hacker to gain access to admin accounts, some attacks will target the website itself.
In 2018, a hacker pleaded guilty to two counts of computer fraud following a three-year hacking spree of US government and military websites. In that instance, Billy Ribeiro Anderson admitted to exploiting XSS vulnerabilities to gain admin privileges, only to then deface the websites with political messages.
Types of XSS attack
Although we've covered the general idea behind a cross-site scripting attack, there are a number of different methods that an attacker can use to exploit the vulnerability.
- Reflected XSS
- Stored XSS
- DOM-based XSS
Reflected XSS is by far the simplest and most common method used.
With this type of XSS attack, the hacker must deliver their payload to a victim manually though a crafted URL containing malicious code. Typically spread through phishing scams, users are encouraged to click a link which will then send a malicious HTML request to a web server, which then reflects this back onto the user's browser, where it's executed.
This same style was used in a string of attacks on eBay in 2014, when hackers used the platform to post fake product listings which included links to fake websites. These URLs were laden with malicious code that executed on a victim's browser when they tried to access the external site. In that instance, the attack placed the user's eBay account at risk, including any saved card details and personal information.
This attack is notably easier to perform than other types of XSS attack, as the payload doesn't need to be stored on the target site's database, where it could be discovered and removed. However, greater awareness of phishing scams and more robust in-built browser protections have made this harder to perform in recent times.
Sometimes called persistent XSS, this style of attack involves tricking a website into storing malicious HTML requests on its database, which can then infect any user requesting access to that server.
To explain, let's consider the following example:
Imagine you're accessing a website that allows users to sell their used clothes. Visitors are able to create accounts and then make a new listing by sending a request to the site's server. The user inputs the name of the item, the price, and a brief description of the quality of the clothing into an online form. This request is then sent to the website's server, where the information is stored and listed for others to see.
A new user may come along and request to see the list of current items for sale, only to find the hacker's listing. Once the user clicks on the description, the script will be secretly executed on their browser.
This attack style is particularly dangerous, as it can spread to any user that accesses the website, and requires very little effort on the part of the hacker.
With the development of ever more sophisticated websites, it's become more difficult to initiate reflected and stored XSS attacks. This has given rise to the DOM-based XSS attack, which, instead of relying on server-side vulnerabilities, triggers malicious scripts inside a user's browser instead of the site server.
This type of attack relies on websites that write data to the user's document object model (DOM) without sanitising that data first. Hackers are able to inject malicious HTML script into a legitimate URL, which can then be sent to a user, much in the same way as a reflected XSS attack. However, rather than sending the script to the website's server once a URL is clicked, the attack waits for a static version of a page to be returned from the server, at which point the user's browser begins to build the DOM of the page. It's at this point that the browser locates the script and runs it.
With DOM-based XSS attacks, the script never reaches the site's server, and therefore is immune to any server-side XSS detection tools.
Defending against XSS attacks
In most cases, XSS attacks can be thwarted by maintaining robust data sanitisation across a website. All data submitted by the user should be subject to as much filtering as possible, including establishing what data is valid or expected for each field. This effectively washes the data clean of any markers that could turn it into executable code.
It's also essential to enforce output encoding on a website. One way to achieve this is to encode HTML tags that would normally signal the start or end of an executable script. For example, < or >, as well as parentheses or punctuation marks, can all be encoded so that a browser simply prints these instead of executing them.
However, more robust policies, such as only accepting links with whitelisted protocols (https:// for example), could also be a good place to start.
BIOS security: The next frontier for endpoint protection
Today’s threats upend traditional security measuresDownload now
The role of modern storage in a multi-cloud future
Research exploring the impact of modern storage in defining cloud successDownload now
Enterprise data protection: A four-step plan
An interactive buyers’ guide and checklistDownload now
The total economic impact of Adobe Sign
Cost savings and business benefits enabled by Adobe SignDownload now