Question: What is an XSS vulnerability? Should I be concerned about an XSS vulnerability?
XSS (short for Cross-Site Scripting) is a widespread vulnerability that affects many web applications. The danger behind XSS is that it allows an attacker to inject content into a website and modify how it is displayed, forcing a victim’s browser to execute the code provided by the attacker while loading the page.
Generally XSS vulnerabilities require some type of interaction by the user to trigger the vulnerability, either via social engineering, or waiting for someone to visit a specific page. That’s why it’s often not taken seriously by developers, but if left unpatched, can be very dangerous.
Imagine you are on your WordPress wp-admin panel adding a new post. If you are using a plugin with a stored XSS vulnerability (explained below) that gets exploited, it can force your browser to create a new admin user while in the wp-admin panel, or it can edit a post and perform other similar actions.
An XSS vulnerability gives an attacker almost full control of the most important software we have on our desktops today: our browsers.
XSS: The Injection Vulnerability
Any website or application has several inputs. They range from form fields to the URL itself, which will become data to be handled by the underlying code. A simple example of this data is when we submit our name, username, password or any other input on a form:
Our name will be stored in the website database for later use, for actions like personalizing our experience in the website. Think for instance when you log into your favorite website and it greets you with your name: “Welcome, John!”.
Each of these data points are considered inputs, and they can be manipulated if the code behind them are not properly validating the inputs and sanitizing the outputs. When an input is specially crafted to contain a certain sequence of characters in order to make the server or even the own browser answer in a desired way, it’s called injection.
This injection type is known as Cross-Site Scripting (XSS): a way to inject code that will perform actions in the browser on behalf of a website. This action can be abrasive and notify the user, or it can work in the background unbeknownst to the user.
Perhaps the most rudimentary Proof of Concept (PoC) you might have come across includes the use of a very basic script tag that generates a popup notifying you of a flaw on the page. That script looks something like this:
<script>alert('THIS IS AN XSS VULNERABILITY!!!')</script>
When this input is accepted by the application and echoed back to the user, it’s evaluated by the user’s browser and executed as if it were native to the website code. It becomes part of the rendered website in that moment, allowing the attacker to perform a number of nefarious acts.
Types of XSS
Not all XSS vulnerabilities are the same. There are a wide range of types and here we’ll provide a very high-level overview of each, including their delivery modes to provide context:
Reference: OWASP XSS Types
Caused by server-side code (Java, PHP, .NET, etc.):
The traditional XSS attacks:
1. Reflected (Non-Persistent) – occurs when the payload gets echoed back to user by opening a link to a vulnerable website with a crafted input.
2. Stored (Persistent) – occurs when the payload gets stored server side and retrieved with every user request to a page.
Also known as DOM-based XSS:
3.Reflected (Non-Persistent) – same as with server side, but this time payload is possible due to code processed by browser.
4. Stored (Persistent) – same as with server side, but this time the payload gets stored in client machine, using browser storage.
Caused by infrastructure (browser, plugins, server, etc.):
Very rare but more dangerous:
5. Client-side infrastructure – occurs when the payload has something to do with the browser’s internals, like its XSS filter or some other core functionality.
6. Server-side infrastructure – occurs when the web server is responsible for a flawed handling of requests allowing modification of response bodies.
7. Network – occurs when it’s possible to tamper the communication between client and server and thus injecting network packet(s) with the payload.
Caused by user:
Commonly seen in scams.
8. Self-XSS – occurs when the user is responsible for injecting the payload in the browser to hack him/herself, usually by means of social engineering.
What Are the Dangers of XSS?
How can I protect my website from XSS? Should I be worried about all of these vulnerabilities I hear in reference to XSS? How can I test my code for it? How can I understand what it really means? There are technologies like the Sucuri Firewall designed to help mitigate these attacks, it’s where I spend my time doing research, but as developers you undeniably want insight on how to identify and account for these weaknesses.
I plan to answer these questions in the upcoming XSS series in which I will work to target and demystify this often misunderstood and undervalued vulnerability. Stay tuned, and join me in the discussion, either in comments or online via twitter via the #asksucuri hashtag.