Introduction to Cross-Site Scripting
Cross-Site Scripting (XSS) is a security vulnerability that primarily stems from inadequate input validation and output encoding within web applications. For bug bounty hunters, XSS is one of the most lucrative and frequently reported vulnerabilities, often fetching significant rewards due as it is easy to find and can have a massive impact.
The sheer prevalence [widespread existence] of XSS is evidenced by its consistent inclusion in the OWASP Top 10 list of the most critical security risks to web applications over the last decade.
This type of vulnerability exists because developers fail to implement strict validation controls across all data entry points in an application. While XSS is traditionally found in HTML forms where users interact directly with the application, vulnerable inputs can also originate from:
- Interactions between other applications.
- Environmental variables.
- External data sources.
A Client-Side Focus
One of the most curious and defining characteristics of XSS is its focus on the client side. Most other common web vulnerabilities target the application itself, exploiting the backend [the server-side code and database] to cause a failure.
In contrast, XSS attacks inject malicious code—usually JavaScript—into a web page viewed by another user. The attack is successful when the victim’s web browser executes the malicious script, meaning these attacks require user interaction to be successful.
Understanding the Core XSS Types
The primary and most fundamental types of XSS attacks are categorized based on how the malicious script reaches and is executed by the victim’s browser.
The Attack Taxonomy
| Primary Types | Community-Specific Variants |
| Reflected XSS | Blind XSS |
| Stored XSS | Flash-based XSS |
| DOM-based XSS | Self XSS |
1. Reflected Cross-Site Scripting
Reflected XSS, sometimes referred to as First-Order XSS, is a non-persistent vulnerability. It is executed at the exact moment a user clicks a malicious link or submits a specially crafted [skillfully made, often deceptive] form.
The malicious script is immediately “reflected” off a web application server and delivered to the user. It most commonly affects GET requests, where the input is sent via the URL parameters.
Impact Explained Through an Example
Imagine a scenario where a user, like your grandmother, receives a phishing email that appears to be from her bank. The email offers a promotion and contains a link. The user, checking the address bar, confirms the bank’s valid domain name, seemingly following good security practices.
However, the link itself contains a malicious payload [the harmful code being delivered], such as:
www.bankforoldpeople.com/access?account='>When the user clicks the link, the bank’s web server takes the unvalidated input from the account parameter and includes it directly in the resulting page displayed to the user. The browser, seeing the unclosed tag ('>) followed by the <script>
// Get the part of the URL containing the parameters
var message = document.location.search.substring(1);
// Write the unvalidated message into the page's HTML
document.getElementById("output").innerHTML = message;
script>
