XSS attacks: what is cross-site scripting and why is it a security risk?

What is cross-site scripting?

A cross-site scripting (“XSS”) attack is a form of injection attack, in which a threat actor executes malicious code into an otherwise benign website. The malicious script targets the web application’s content and is then delivered to end-users browsers as they interact with the application – and the victim is often none the wiser. This potentially enables the threat actor to access the user’s website data, cookies and even take over the session. If the user has administrative access to the application, the attacker could potentially exploit the application’s underlying functionality.  

The severity of the XSS threat is well documented within the web application development industry. It is the third most prevalent issue in the OWASP Top 10, found in the injection category. According to OWASP, XSS flaws are found in roughly two-thirds of all applications today.  

In the age of e-commerce, XSS vulnerabilities can be used to steal credit card information in poorly secured web applications. As an example, take the British Airways data breach of 2018. In this incident, the malicious group, Magecart, leveraged XSS to obtain confidential credit card information relating to over 380,000 booking transactions. 

What are injection attacks?

An injection is a broadstroke term that defines a number of attack vectors, centred around a malicious actor finding an input validation flaw in a web application. They will then post malicious data or code into the website input field or parameter in order to manipulate how the application operates, or what data is returned. In some cases, the code is entered in the language of the target application (for example, Python, PHP or Java) and then executed by the server-side interpreter. In others, the attack injects JavaScript, which runs in the user’s browser. 

The aim of these attacks is multi-fold. Threat actors can, for example, compromise sensitive data, hijack user sessions and sometimes even execute operating system calls on target machines. These attacks can both compromise backend systems and the systems of end-users that connect to the application, as is the case in XSS attacks. Other common forms of injection attacks include SQL injections and OS Command Injections.  

Why are XSS flaws so prevalent?

Most applications today run on internet-accessible web servers and possess the functionality to collect and display user data – such as a comment section or review section. This functionality is accessible to users across the world, some of whom could be threat actors. That is why API testing is critical to your organisation. 

XSS attacks, specifically, occur when the web application accepts visitor input, which is then poorly (or not completely) sanitised. Through this input mechanism, a threat actor can inject malicious code that is then legitimately executed by the browser.  

The fact is, today’s web applications are made by people and, at some point or another, people will make mistakes. Just one small coding mistake could make an application vulnerable to an XSS flaw. As the saying goes, the defending team must win every time, the attacking team only has to win once. Moreover, today’s web applications are rarely static. Developers make updates continuously, meaning that, even if an application is secure at one point in time, it may not be secure at another.  

How do cross-site scripting attacks work?

There are three main types of XXS attacks: stored (persistent XSS), reflected (non-persistent XSS), and DOM-based XSS. The output of each attack may be alike, but the three kinds vary significantly in the way the malicious payload is delivered. 

Stored XSS  
Stored XSS occurs when a web application’s user input is not sanitised and saved to the server-side. A threat actor will input malicious code into this form. Then, when a user opens the page that contains the malicious script, the payload automatically executes in the browser as a valid part of the page. The malicious code will not necessarily be visible on the server-side or to end-users, allowing the attack to potentially go unnoticed and impact multiple people.  

Reflected XSS 
Reflected XSS occurs when a web application immediately returns a user input in an error message or other form of output on the page. To do this, a threat actor will typically use a phishing email or malicious advert to trick a user into clicking a fraudulent link. When the user clicks this link, the script executes in their browser.  

DOM Based XSS 
DOM-based XSS stands for Document Object Model-based cross-site scripting. These attacks take place when an attacker is able to control some part of the client-side JavaScript used in the page. The page then executes differently as a result of these malicious edits within the DOM environment. 

Types of Cross-Site Scripting attacks

The three forms of XSS attacks often overlap. For example, both stored and reflected DOM-based XSS attacks exist – as do stored and reflected non-DOM based XSS attacks. This intersection can create confusion for web application developers and researchers so, in 2012, OWASP’s research community published two new terms to better clarify the types of XSS attacks: Server XSS and Client XSS.  

Server XSS
In a Server XSS attack, the threat actor injects the malicious payload into the victim’s web browser from a web server. The source of the payload can be from the HTTP request or from a stored location – meaning it could be either a Reflected Server XSS or Stored Server XSS.  

Client XSS

In a Client XSS attack, the threat actor injects the malicious payload to update the DOM, typically with a malignant JavaScript call, or via some untrusted data source that is utilised by the JavaScript on the page.  

With these new definitions, the definition of DOM Based XSS doesn’t change. DOM Based XSS is simply a subset of Client XSS, where the source of the data is somewhere in the DOM, rather than from the Server. 

How to prevent and manage XSS vulnerabilities

Organisations can mitigate XSS vulnerabilities, firstly, by incorporating security by design into the web application development lifecycle. We advise that app developers utilise mature frameworks such as Ruby on Rails, React JS, or Django (among many others!) which all provide out-of-the-box mitigations for these types of attacks. The OWASP cheat sheet on XSS prevention is also a good resource to review.  

However, even with an increased focus on security by design, vulnerabilities will still slip through the net. This is especially true in the fast-paced world of application and web design, where updates occur regularly, and developers are often under tight deadlines to release updates.  

As a method of assurance, organisations should also implement regular vulnerability scanning combined with manual web application penetration testing. Automated tools, such as Burp Suite and OWASP Zap, can discover some – but not all – XSS problems, while manual penetration testing will discover more complex XSS application flaws. We recommend implementing monthly vulnerability scanning along with penetration testing at an annual interval – or after a major change to the application.  

For more information on this topic, please refer to our blog on authenticated web app penetration testing and our broader guide to the different types of penetration tests.  

Need an API pen test?

If your organisation needs help with a web application pen test or an infrastructure penetration test, we’re here to help. We can assess your environment and run a full penetration test. We can also advise you on any follow-up actions or remediations from our findings. Contact us for a friendly chat. 

Want to learn more about the common vulnerabilities found with penetration testing? Read our blog on the topic. Or to take a deeper dive into what a penetration test costs in the UK.