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.

The majority of attacks tend to use JavaScript to execute code in a victim's browser, however other languages such as Java, Flash and Ajax are also sometimes used.

Impact of a successful XSS exploit

Targeting users

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.

As browsers and user habits have developed, new opportunities for theft have also arisen. Modern browsers now make use of HTML5, something that malicious JavaScript can also exploit to gain access to additional data such as files stored on a user's system or even their webcam. It's also possible to use an XSS vulnerability to target a user's passwords, although this is only possible with users that have password managers that autofill data into online forms.

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.

Targeting websites

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.

These are:

  • Reflected XSS
  • Stored XSS
  • DOM-based XSS

Reflected 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.

Stored XSS

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.

Now imagine a hacker discovers this website, and begins to probe for weaknesses by following the same steps above, only they notice that the submission form provides the option to customise the text using HTML code. Instead of providing a description for an item of clothing, they instead place a piece of custom JavaScript, which is then sent to the website's server, and stored for others to access.

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.

DOM-based XSS

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.

Finally, for those who are interested in seeing an XSS exploit in action, or for those developers who would like to better understand how to code against such vulnerabilities, Google has developed a handy simulation game to demonstrate how easy it is. The game is spread across six levels of difficulty all you need is some JavaScript and Python knowledge to get started.

Featured Resources

How to scale your organisation in the cloud

How to overcome common scaling challenges and choose the right scalable cloud service

Download now

The people factor: A critical ingredient for intelligent communications

How to improve communication within your business

Download now

Future of video conferencing

Optimising video conferencing features to achieve business goals

Download now

Improving cyber security for remote working

13 recommendations for security from any location

Download now

Most Popular

How to find RAM speed, size and type

How to find RAM speed, size and type

26 Feb 2021
How to connect one, two or more monitors to your laptop

How to connect one, two or more monitors to your laptop

25 Feb 2021
How to use Chromecast without Wi-Fi

How to use Chromecast without Wi-Fi

26 Feb 2021