Cross-site scripting, also known as XSS, is one of the web vulnerabilities in the TOP 10 Owasp list.
What is XSS in Cybersecurity?
XSS is one of the most common JavaScript vulnerabilities. Learn here how you can efficiently fix XSS vulnerabilities.
The number of severe vulnerabilities per web application is rising each year. Often developers also have to tackle vulnerabilities that they’ve never seen before. These Zero-Day attacks are why development teams need to proactively search for vulnerabilities within their web application before releasing new features to the public.
Learn here how you can efficiently fix XSS vulnerabilities.
What is an XSS Attack?
Cross-site scripting (XSS) is the injection of client-side scripts into web applications, which is enabled by a lack of validating and correctly encoding user input. The malicious scripts are executed within the end user’s browser and enable various attacks, from stealing the end-users session to monitoring and altering all actions performed by the end-user on the affected website. This is possible whenever user input (for example, on a website) is not sufficiently validated on the client- or the server-side.
This includes altering all user actions on that website since the browser does not know that this script cannot be trusted. Because this script is trusted, it can access, e.g., cookies or session tokens or even alter the content of an HTML Page.
It can be injected persistently or non-persistently, depending on the type of XSS that is being used. Usual vehicles of cross-site scripting attacks include search forms, forums, or comment sections.
XSS Security Assessment Level
CVSS Vector: AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Cross-Site Scripting (XSS) Types
There are different types of XSS attacks, which distinguish if the malicious scripts could be injected in a non-persistent or persistent fashion. Furthermore, there is a differentiation between the vulnerability caused by a flawed input validation on the client- or server-side.
There 3 main types of cross-site scripting attacks are:
- Stored XSS
- Reflected XSS
- DOM-based XSS
Stored Cross-Site Scripting (Persistent)
A Stored Cross-site Scripting vulnerability allows an attacker to inject a malicious script persistently into a web application.
In a Stored XSS example, the script might have been submitted via an input field to the web server, which did not perform a sufficient validation and stores the script persistently in the database. The consequence of this might be that this script is now being delivered to all users visiting the web application and, e.g., able to gain access to the user’s session cookies.
- The script is persistently stored in the web app
- Users visiting the app after the infection retrieve the script
- Malicious code exploits flaws in the web application
- The script and the attack are visible on the server-side (to the app owner)
Reflected Cross-Site Scripting (Non-Persistent)
A Reflected Cross-site Scripting Vulnerability appears if unvalidated input is directly displayed to the user.
In a Reflected XSS example, the input of a search form is reflected on the page to show what the search key was. An attacker may craft an URL that contains malicious code and spread the URL via e-mail or social media. A user who clicks on this link opens the (valid) web application, which then runs the malicious code in the user’s browser.
- The script is not stored in the web application
- Malicious code is shown to only one user
- Users that open the link execute the script when the app is opened
- The script and the attack are not necessarily visible on the server-side (to the app owner)
DOM-Based Cross-Site Scripting
DOM stands for Document Object Model and is an interface to web pages. It is essentially an API to the page, allowing programs to read and manipulate the page’s content, structure, and styles.
A DOM-based XSS attack may be successfully executed even when the server does not embed any malicious code into the webpage by using a flaw in the JavaScript executed in the web browser. For example, if the client site JavaScript modifies the DOM tree of the webpage based on an input field or GET parameter without validating the input, malicious code can be executed.
- The script is not stored in the web application
- Malicious code is shown to only one user
- Malicious code exploits flaws in the browser on the user side
- The script and the attack are not necessarily visible on the server-side (to the app owner)
Risk of XSS Vulnerabilities
Because a Cross-Site Scripting attack infects the user’s browser, you might think it is pretty harmless to your web application. But, unfortunately, nothing could be further from the truth:
An attacker could change parts of the web page or send the user to another (potentially malicious) web page through the injected script. Your user will notice and be less likely to go on using your web application in any way.
There are simple ways to reduce the risk of Cross-Site Scripting attacks for users since add-ons for some browsers protect from specific malware attacks. However, as the application provider, you shouldn’t trust that all of your users have these included, which is why you should take action yourself.
How to Prevent XSS Attacks?
Cross-Site Scripting vulnerabilities are hard to identify and remediate. What can you do so? to prevent XSS attacks, treat all user input as potentially malicious and follow some programming guidelines:
Avoid Untrusted Input
XSS attacks only appear if any user input is displayed on the webpage. Therefore try to avoid displaying any (untrusted) user input, if possible. If you need to display user data, restrict the places where the user input might appear. Any input displayed inside a JavaScript tag or a URL shown on the site is much more likely to be exploited than the input that appears inside a div or span element inside the HTML body.
Filter User Input
When any untrusted input is shown as normal text inside an HTML tag, filter out the characters that allow an attacker to insert a <script> tag on the page. Use the following functions for that:
htmlspecialchars($input) # PHP
html.escape(input, quote=True) # Python
org.apache.commons.lang.StringEscapeUtils.escapeHtml(input) # JavaIn JavaScript, you need to define an extra function for this task. You may use:
function escapeHtml(text) {
var map = {
'&': '&',
'<': '<',
'>': '>',
'"': '"',
"'": '''
};
return text.replace(/[&<>"']/g, function(m) { return map[m]; });
}When user input needs to be inserted into tag attributes or inside a script, you will need to use stronger escape mechanisms. Refer to the XSS Prevention Cheat Sheet for more information. This is the case if you plan to allow user input in cases such as:
<a href="http://example.org/search/q?...USER INPUT..."></div>
<script>alert('...USER INPUT...')</script>
<style> { property: ...USER INPUT...; } </style>Fix DOM-based XSS
To prevent a DOM-based XSS attack you could use a save JavaScript property like ‘element.text content for untrusted user input. This prevents the browser from rendering the potential JavaScript code inside the ‘untrustedVariable.’ One of the Dom XSS examples could look like the following code snippet:
element.textContent = untrustedVariableFurthermore, it is important to use secure JavaScript functions like ‘inner text or ‘text content instead of ‘innerHtml.’ It is always good to keep in mind that it is perilous to pass user-controlled inputs into your web application without proper sanitization.
For further information, OWASP provides a specific DOM-based XSS Prevention Cheat Sheet, including an additional set of rules for securing your web application from DOM-based XSS.
Prevention Guide
XSS Prevention Guide
Cross-site scripting (XSS) is one of the most commonly known injection attacks. Learn how to detect and prevent it. Download this guide for free.
Use an XSS Vulnerability Tool
As mentioned earlier, XSS attacks are sometimes difficult to detect. However, this can be changed if you get some external help. Another way to prevent XSS Attacks is using the XSS Tool from Crashtest Security Suite – a web vulnerability scanner with a 14-day free trial where you will find any vulnerability you could be exposed to. Still, manual testing is highly time-consuming and costly – and therefore not possible to be done for every iteration of your web application.
Consequently, your code shouldn’t be untested before any release.
Using automated security, you can scan your web application for Cross-Site Scripting and other critical vulnerabilities before every release you do. This way, you can ensure that your web application’s Live-Version is still secured whenever you alter or add a feature.
Enable Content Security Policy (CSP)
This can prevent not just Cross-Site Scripting attacks but also Cross-Site Injection attacks.
Videos Explaining XSS and its Prevention
Frequently Asked Questions
Which are the most common attacks using XSS?
- Control of the victim’s computer
- DOM node replacement
- ATO (Account Takeover)
- Cookie Grabber
Which is the impact of Cross-Site Scripting?
For Reflected XSS and DOM-based XSS, the impact is moderate. For Stored XSS the impact is considered severe.
Is XSS really a problem?
Yes. Understanding how XSS works and its risks to your business is crucial. There are many examples of companies being hacked due to XSS issues. Some of these include:
Paypal
Yahoo
Microsoft
Is XSS more prevalent than SQLi?
Yes, XSS is far more prevalent than SQLi. This is because of the nature of XSS attacks. They are easier to perform and less likely to be detected by automated scanners.
