Hello, I am Mayank, an undergraduate student with an interest in web application security and penetration testing. This write-up documents my learning and practical understanding of Cross-Site Scripting (XSS).
This write-up focuses on explaining XSS vulnerabilities in a clear and structured manner and covers different types of XSS using hands-on labs from multiple security learning platforms. The goal is to make the concepts easy to understand while demonstrating real-world exploitation scenarios, their impact, and effective mitigation techniques.
What is Cross-Site Scripting (XSS)?
Cross-Site Scripting (XSS) is a client-side vulnerability where a web application takes user input and sends it back to the browser without proper validation or encoding, allowing malicious JavaScript to execute in a victim's browser.
In simple terms:
- The website trusts user input
- Attacker injects JavaScript
- Victim's browser executes it as if it came from the website
Why XSS happens
- User input is reflected, stored, or processed without sanitization
- Output is not context-aware encoded
- Dangerous JavaScript sinks are used
What an attacker can do
- Steal session cookies
- Perform actions as the victim
- Deface pages
- Redirect users to malicious sites
- Target admin users
Types of Cross-Site Scripting (XSS)
Cross-Site Scripting vulnerabilities are commonly classified based on how and where the malicious script is injected and executed. In this write-up, each major type of XSS is explained using a representative vulnerable lab to demonstrate real-world exploitation, impact, and mitigation.
- Reflected XSS — Reflected XSS is a type of XSS vulnerability where user-supplied input is immediately returned in the HTTP response without proper encoding or sanitization. The injected script is executed by the victim's browser when a specially crafted request is processed by the application.
How Reflected XSS Works (Attack Flow)
- An attacker identifies a parameter where user input is reflected in the response.
- The application fails to properly encode or sanitize this input.
- The attacker crafts a malicious URL containing JavaScript code.
- This URL is delivered to the victim via phishing, email, or social engineering.
- When the victim clicks the link, the request is sent to the vulnerable application.
- The application reflects the malicious input in the response.
- The victim's browser executes the script in the context of the vulnerable website.
Key point: Reflected XSS requires user interaction (e.g., clicking a crafted link).
Lab Demonstration: Reflected XSS (PortSwigger)
Lab Overview
This lab demonstrates a basic reflected Cross-Site Scripting (XSS) vulnerability where user input is reflected directly into the HTML response without any encoding. As a result, injected JavaScript is executed by the browser.
The lab is provided by PortSwigger Academy.
Methodology
To identify the vulnerability, the application functionality was first analyzed to understand how user input is handled. A search feature was identified where user-supplied input is reflected back in the response. This behavior indicated a potential reflected XSS vulnerability if proper output encoding was missing.
Steps to Reproduce
- Open the lab and observe the lab description and objective.
- Navigate to the search functionality and enter a benign test input (e.g.,
basic xss) in the search bar. - 3. After submitting the search, observe that the search term is reflected in the response page without encoding.
4. Replace the search input with the following payload and submit the request:
<script>alert(1)</script>
5. The injected JavaScript executes in the browser, displaying an alert box and solving the lab.
Proof of Concept (PoC)
<script>alert(1)</script>This payload works because the input is reflected directly into an HTML context without sanitization or encoding.
Impact
If this vulnerability exists in a real-world application, an attacker could:
- Execute arbitrary JavaScript in a victim's browser
- Steal sensitive information such as session cookies
- Perform actions on behalf of authenticated users
- Use crafted URLs for phishing attacks
Root Cause
- User input is reflected directly in the HTML response
- No output encoding or validation is applied
- Browser interprets injected input as executable code
Mitigation
- Apply context-aware output encoding
- Avoid reflecting raw user input in responses
- Validate and sanitize all user-controlled input
- Implement a strict Content Security Policy (CSP)
Wrapping Up (Part 1)
In this part, we explored Reflected Cross-Site Scripting (XSS) using a basic lab to understand how untrusted user input can be reflected into an HTML response and executed in the browser. This lays the foundation for understanding more impactful XSS scenarios.
In Part 2, I'll continue with:
- Stored XSS
- DOM-based XSS
- More practical XSS labs and bypass techniques
📬 Stay Connected
If you found this helpful and want to learn more about web security, XSS, and hands-on labs, feel free to follow me for upcoming posts.
✍️ Medium — Follow me for more cybersecurity write-ups 🔗 LinkedIn — codermayank 📸 Instagram — @mayhack_