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?
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 which could be threat actors.
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 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 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
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.
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.
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.
If your organisation needs help running a penetration test on an application or infrastructure, 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.