CHALLENGE INFORMATION
![]() | Platform: TryHackMe Event: Advent of Cyber 2025 Day: 11 Title: XSS - Merry XSSMas |
Description
Learn about types of XSS vulnerabilities and how to prevent them.
Summary
Here, we first exploit a reflected XSS vulnerability, then a stored XSS one.

Storyline
Santa’s workshop was modernized with a secure message portal for McSkidy, but logs show unusual activity: odd messages, suspicious search terms, and code disguised as letters. The mission is to investigate and identify who’s causing the mischief.
Leave the Cookies, Take the Payload
Cross-Site Scripting (XSS) is a web vulnerability where attackers inject malicious code (typically JavaScript) into input fields that other users view.
It occurs when applications fail to properly validate or escape user input, allowing it to be executed as code rather than treated as text.
Types of XSS
Reflected XSS
Reflected XSS occurs when malicious code is immediately returned in the response and executed in the victim’s browser. It typically targets individual users through phishing links and does not persist on the server.
Example:
<!-- original request -->
https://trygiftme.thm/search?term=gift
<!-- request with reflected xss -->
https://trygiftme.thm/search?term=<script>alert( atob("VEhNe0V2aWxfQnVubnl9") )</script>
Stored XSS
Stored XSS is more dangerous – malicious scripts are saved on the server and automatically executed for every user who views the affected page. This attack affects all visitors without requiring them to click a link.
Potential Impact: Both types allow attackers to steal credentials, deface pages, impersonate users, steal session cookies, trigger fake login popups, and access information the victim could access.
Cheat Sheet from PortSwigger: Cross-site scripting (XSS) cheat sheet
Protection Strategies
Disable dangerous rendering: Use textContent instead of innerHTML to treat input as plain text rather than executable code.
Secure cookies: Set HttpOnly, Secure, and SameSite attributes on session cookies to limit XSS damage.
Sanitize and encode input/output: Remove or escape executable elements (scripts, event handlers, JavaScript URLs) while preserving safe formatting, especially when limited HTML input is necessary.
Questions and Answers
Question-1: Which type of XSS attack requires payloads to be persisted on the backend?
stored
Question-2: What’s the reflected XSS flag?
<redacted-flag>
We first visit the target web application.
To validate our findings, we craft a sample JavaScript alert to verify the Reflected XSS vulnerability via the provided search bar, then click Search Messages.
For the payload, we use the cat example:
<script>alert('Reflected Meow Meow')</script>
Once the request is sent, a popup appears, verifying the presence of a Reflected XSS vulnerability.

Figure 1: JavaScript alert popup confirming reflected XSS vulnerability
Successfully triggering the Reflected XSS vulnerability provides the necessary flag.

Figure 2: Reflected XSS flag displayed after successful payload execution
Question-3: What’s the stored XSS flag?
<redacted-flag>
This time, our goal is to verify whether a stored XSS vulnerability exists via the web application’s send message function, which stores messages on the server.
As before, we use the cat payload:
<script>alert('Stored Meow Meow')</script>
Once the message is sent, the intended popup appears, verifying that the web application is indeed susceptible to stored XSS.

Figure 3: JavaScript alert popup confirming stored XSS vulnerability
Finally, once the Stored XSS vulnerability is triggered, the flag appears under Recent Messages.

Figure 4: Stored XSS flag displayed in Recent Messages section
Question-4: If you enjoyed today’s room, you might want to have a look at the Intro to Cross-site Scripting room!
No answer needed
