Lab 1: Reflected XSS into HTML context with nothing encoded

 

✅ 1. What the Lab Is About (Simple Summary)

This PortSwigger lab demonstrates reflected Cross-Site Scripting (XSS) in a page where:

• The server takes user input from the URL

• The page injects that input directly into HTML

• Nothing is encoded or sanitized

Because of that, an attacker can craft a link that makes the browser run unintended JavaScript.

The lab goal:
➡️ Inject a harmless script payload to show an alert.

---

🧠 2. Analogy: “The Classroom Announcer”

Imagine a teacher who reads out all messages handed to them, exactly as written, without checking.

If a student writes:

“Today’s homework is canceled!”

…the teacher reads it out loud, even though it wasn’t real.

This lab is the same idea:
The website takes whatever the user writes (in the URL) and announces it inside the page without checking.

If someone adds:

"><script>alert('XSS')</script>

…then the “teacher” (browser) reads it out loud and executes it.

---

🔍 3. How the Vulnerability Works

The page contains HTML like this:

<p>You searched for: <span id="q">USER INPUT HERE</span></p>

If the developer inserts the value like this:

<span id="q"><?php echo $_GET['search']; ?></span>

…then dangerous characters like " < > are not encoded.

This allows the user to break out of the HTML context and inject script.

---

🧪 4. Steps of Exploitation (Student-Friendly)

1. Find where user input appears on the page

   • In the search box, or URL parameter like ?search=abc.

2. Confirm the page reflects the input

   • Change the value and reload.

   • If the text appears unchanged → potential XSS.

3. Test for HTML injection
   Try breaking the HTML context:

   "
   '
   >
   

4. Inject a harmless script payload
   Example (the lab’s goal):

   <script>alert(1)</script>
   

5. Submit the payload
   If the alert pops, the lab is solved.

---

🧨 5. Example of Vulnerable Code (Analogous to the Lab)

<?php
$search = $_GET['search'];
echo "<p>You searched for: $search</p>";

Why this is vulnerable:

• User input is inserted directly into HTML

• No encoding

• No sanitization

• Browser interprets malicious HTML/JS

---

🛡️ 6. How to Fix the Bug Properly

✔️ Safe Fix: HTML Escape Output

In PHP:

<?php
$search = htmlspecialchars($_GET['search'], ENT_QUOTES, 'UTF-8');
echo "<p>You searched for: $search</p>";

This converts dangerous characters:

• < → <

• > → >

• " → "

The browser displays them but does not execute them.

---

✔️ Alternative Fixes (High-Level)

• Use frameworks that auto-escape output (React, Django, Ruby on Rails)

• Avoid mixing HTML and user data

• Validate input when applicable

• Set strong Content Security Policy (CSP) (defense-in-depth)

---

📘 Summary (One Sentence)

This lab teaches that when user input is placed inside HTML without encoding, the user can inject markup or script, and the fix is to properly escape output before rendering it in the page.

References:

https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded