3 Types of XSS Attacks & 4 XSS Mitigation Strategies

Cross site scripting (XSS) is an application security vulnerability that allows a hacker to inject malicious code into a website or mobile application. XSS flaws have been known and studied since the 2000s. Despite their popularity and plague, they are still frequently found and do not show signs of disappearing anytime soon. The impact of an XSS attack can be an important finding in penetration testing. XSS attacks occur when a malicious user enters a piece of code as input data. The malicious code is eventually interpreted as DOM markup and runs on a victim’s browser. With their code running on the victim’s browser, the attacker is able to steal confidential information and perform other actions in the context of that user, also bypassing numerous security controls like the same-origin policy.

Three Types of XSS Attacks

Stored XSS

Stored XSS is when the malicious script is injected into a vulnerable app where it is persisted or stored on the vulnerable page of the application.  When a victim loads the affected page in the application the malicious script will execute the context of a user’s session. Here is an example of stored XSS in the Elementor Page Builder tool.

Reflected XSS

Reflected XSS attacks occur when a victim is tricked by the attacker into visiting a malicious link within the vulnerable application. The malicious link may be introduced to the victim via social engineering, phishing, or watering hole style attacks.  In this scenario these non-persistent scripts are injected into a user’s browser session and executed as a direct reflection within HTTP responses returned by the server. Here is an example of reflected XSS in the Jetbrains TeamCity tool.

DOM Based XSS

DOM based XSS also involves a malicious link and may be introduced to the victim in a similar attack vector as reflected XSS, although unlike what we’ve seen so far DOM-based XSS attacks do not require interaction with a server. The attacker’s code is stored and executed in the browser. Thus, securing our server-side code will offer no protection against DOM-based attacks. The attack’s independence from the server also makes detection more complex.

Why XSS issues are growing in popularity

Actions an attacker can take when their code is running on a user’s browser include:

• Steal the user’s sensitive information, such as login credentials, credit card information, and other private/sensitive data.
• Hijack a user’s session (if your application allows JavaScript to read HTTP session information).
• Send and receive data from a malicious web server.
• Access the user’s webcam, microphone, and location through HTML 5 APIs or other known browser vulnerabilities.
• Advanced phishing techniques that will be difficult for both non-technical and technical users to identify.

The presence of XSS vulnerabilities depends on various factors, and these factors explain why such flaws are still being found at an increasing rate. Not all developers are necessarily trained in the risks associated with XSS and the impact of these vulnerabilities are sometimes not perceived correctly. As systemic security starts with the code, developers lack the knowledge and frameworks to integrate and manage many security elements. When a site or an application is coded without a framework, it is unfortunately easy to write code that is vulnerable to XSS and to overlook the verifications and controls of the data received.

Mitigating XSS attacks

No single technique will solve XSS. But, using the right combination of defensive techniques is necessary to prevent XSS. There are various ways to try and protect yourself and your organization from this class of vulnerability, and we will go into various prevention methods.

Establish framework security

Fewer XSS bugs appear in applications built with modern web frameworks. These frameworks steer developers towards good security practices and help mitigate XSS by using templating, auto-escaping, and more. Understand how your framework prevents XSS and where it has gaps. There will be times where you need to do something outside the protection provided by your framework. This is where Output Encoding and HTML Sanitization are critical. OWASP are producing framework specific cheat sheets for React, Vue, and Angular.

Practice XSS defense philosophy

For XSS attacks to be successful, an attacker needs to insert and execute malicious content in a webpage. Each variable in a web application needs to be protected. Ensuring that all variables go through validation and are then escaped or sanitized is known as perfect injection resistance. Any variable that does not go through this process is a potential weakness. Frameworks make it easy to ensure variables are correctly validated and escaped or sanitized.

However, frameworks aren't perfect and security gaps still exist in popular frameworks like React and Angular. Output Encoding and HTML Sanitization help address those gaps.

Use output encoding

Output encoding is recommended when you need to safely display data exactly as a user typed it in. Variables should not be interpreted as code instead of text. This section covers each form of output encoding, where to use it, and where to avoid using dynamic variables entirely.

Start with using your framework’s default output encoding protection when you wish to display data as the user typed it in. Automatic encoding and escaping functions are built into most frameworks.

If you’re not using a framework or need to cover gaps in the framework then you should use an output encoding library. Each variable used in the user interface should be passed through an output encoding function. A list of output encoding libraries is included in the appendix.

There are many different output encoding methods because browsers parse HTML, JS, URLs, and CSS differently. Using the wrong encoding method may introduce weaknesses or harm the functionality of your application.

Do HTML sanitization

Sometimes users need to author HTML. One scenario would be to allow users to change the styling or structure of content inside a WYSIWYG editor. Output encoding here will prevent XSS, but it will break the intended functionality of the application. The styling will not be rendered. In these cases, HTML Sanitization should be used.

To learn more about XSS protection and specific output coding code snippets, visit OWASP’s XSS Cheat Sheet.