Introduction

In this write-up, I will demonstrate how I solved the Reflected XSS lab on PortSwigger Academy. This lab is a great example of how improper handling of user input can lead to Cross-Site Scripting vulnerabilities.

The Vulnerability

The application takes input from the search bar and reflects it directly into the page without performing any HTML encoding or sanitization.

None

Steps to Reproduce

1. Identifying the Reflection Point

First, I went to the blog's homepage and typed a unique string, sedky, into the search bar to see where it appeared in the page's source code.

  • Observation: The string was reflected on the results page.

2. Inspecting the HTML Code

Using the Inspect Element tool, I checked the HTML structure. I found that my input was placed directly inside an <h1> tag:

<h1>0 search results for 'sedky'</h1>
None

3. Testing for XSS

Since the input was not encoded (the characters < and > were still there), I realized I could inject HTML tags. I used a simple JavaScript payload to trigger an alert box.

<script>alert(1)</script>

4. Execution Confirmation: The application processed the request and rendered the script as part of the HTML. The browser then executed the code, resulting in a successful alert box popping up on the screen.

None

Payload Used:

<script>alert(1)</script>

Impact

A Reflected XSS vulnerability allows an attacker to:

  • Steal session cookies.
  • Redirect users to malicious phishing websites.
  • Modify the page content (Defacement).
  • Capture sensitive information typed by the user (Keylogging).

Remediation (How to Fix)

To prevent this vulnerability, the application should:

  1. Output Encoding: Use proper HTML encoding (e.g., converting < to < and > to >) before rendering user input in the browser.
  2. Input Sanitization: Implement a strict allow-list for expected characters in the search field.
  3. Content Security Policy (CSP): Implement a strong CSP to restrict the execution of unauthorized scripts.

Conclusion

The lab was successfully solved! This vulnerability occurred because the application trusted user input and rendered it as part of the HTML. To fix this, developers should always use Output Encoding to ensure that special characters are treated as text, not as code.

Happy Hacking!