THM Merry XSSmas Writeup: Learning Reflected and Stored XSS Attacks

Introduction

The Merry XSSmas room demonstrates how improper input handling can lead to dangerous client-side vulnerabilities.

This challenge focuses on two common web vulnerabilities:

• Reflected XSS

• Stored XSS

The lab combines log analysis, JavaScript payload injection, and browser behavior to demonstrate how attackers can execute arbitrary scripts inside a victim’s browser.

By exploiting these vulnerabilities, both hidden flags can be recovered from McSkidy’s vulnerable message portal.

---

Lab Information

Category	Value
Platform	TryHackMe
Room	Merry XSSmas
Event	Advent of Cyber 2025
Difficulty	Easy
Focus Area	Web Security

---

Understanding Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) occurs when a web application returns unsanitized user input directly to the browser.

If JavaScript code is injected successfully, the victim’s browser executes the payload as trusted code.

Common impacts include:

• Session hijacking

• Credential theft

• Cookie stealing

• Redirecting users

• Defacing web pages

• Executing malicious JavaScript

This room demonstrates two major XSS categories.

---

What Is Reflected XSS?

Reflected XSS occurs when user-controlled input is immediately reflected inside the server response without sanitization.

This commonly appears in:

• Search bars

• URL parameters

• Query strings

• Error messages

The payload is executed instantly when a victim visits a crafted URL.

Example:

<script>alert(1)</script>

If the server reflects this payload back into the webpage, the browser executes the JavaScript.

---

What Is Stored XSS?

Stored XSS is more dangerous because the malicious payload is permanently stored on the backend.

Every time another user loads the affected page, the payload executes automatically.

Common targets include:

• Blog comments

• Forums

• User profiles

• Message boards

• Chat systems

Stored XSS becomes persistent because the malicious script survives page reloads and affects multiple users.

---

Identifying the Attack Surface

The portal exposes multiple user-controlled input fields:

1. A search bar

2. A message submission form

Both features return user input directly into the browser without proper sanitization or escaping.

This immediately suggests testing for client-side script injection.

---

Exploiting the Reflected XSS Vulnerability

The first target was the search functionality.

Testing with a basic payload immediately confirmed reflected XSS.

<script>alert('You Have been H4cked')</script>

The browser executed the payload successfully.

The challenge hints toward Base64-encoded JavaScript payloads for recovering the official flag.

The following payload was used:

<script>alert(atob("VEhNe0V2aWxfQnVubnl9"))</script>

The JavaScript atob() function decodes Base64 content directly inside the browser.

When executed, the payload reveals the flag:

THM{Evil_Bunny}

---

Reflected XSS Flag :

THM{Evil_Bunny}

---

Exploiting the Stored XSS Vulnerability

The second attack targets the message submission form.

Since submitted messages are stored on the backend and displayed later, this creates a persistent XSS attack surface.

Initial testing:

<script>alert('H4cked by stored')</script>

The payload executed every time the page refreshed, confirming stored XSS.

The official payload used:

<script>alert(atob("VEhNe0V2aWxfU3RvcmVkX0VnZ30="))</script>

Once triggered, the browser decodes the Base64 string and displays the second flag.

Decoded result:

THM{Evil_Stored_Egg}

---

Stored XSS Flag :

THM{Evil_Stored_Egg}

---

Why the Vulnerability Exists

Both vulnerabilities exist because the application directly inserts user-controlled input into HTML responses without sanitization.

The application fails to:

• Escape HTML characters

• Validate dangerous input

• Filter JavaScript tags

• Encode user content safely

As a result, arbitrary JavaScript executes inside the browser context.

---

Mitigation Techniques

Proper mitigation requires both frontend and backend protections.

---

1. Escape User Input

Special characters should always be encoded before rendering:

<  >  "  '  /

This prevents browsers from interpreting injected HTML or JavaScript.

---

2. Avoid Using innerHTML

Using:

element.innerHTML = userInput;

allows attackers to inject arbitrary HTML and scripts.

Safer alternative:

element.textContent = userInput;

textContent treats all input as plain text instead of executable HTML.

---

3. Sanitize HTML Properly

If applications require formatted user content, use trusted sanitization libraries such as:

DOMPurify

Whitelist-based sanitization is significantly safer than manual filtering.

---

4. Harden Session Cookies

Secure cookie settings reduce the impact of XSS attacks.

Recommended flags:

HttpOnly
Secure
SameSite=Strict

These protections help prevent session theft and unauthorized cookie access.

---

Lessons Learned

This room demonstrates several important web security concepts:

• Difference between reflected and stored XSS

• How browsers execute injected JavaScript

• Why unsanitized input becomes dangerous

• Risks of rendering user-controlled content

• Importance of output encoding and sanitization

• Safe frontend rendering practices

---

Conclusion

Merry XSSmas provides an excellent beginner-friendly introduction to client-side web vulnerabilities and JavaScript injection attacks.

The challenge demonstrates how unsanitized user input can lead to both reflected and stored XSS vulnerabilities, allowing attackers to execute arbitrary JavaScript inside victim browsers.

It also reinforces the importance of secure input handling, output encoding, and frontend security best practices in modern web applications.

---

Flags Obtained :

THM{Evil_Bunny}
THM{Evil_Stored_Egg}

---

Happy hacking 🎄🔐