Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a web application vulnerability in which user-supplied content can be interpreted by a browser as executable client-side content. In this lab, the objective was to locate an input point where XSS could be demonstrated and obtain the flag provided by the training environment.

2. Objective

The objective of the lab was to identify an XSS injection point, test the application with suitable payloads, successfully trigger JavaScript execution, and capture the resulting flag.

3. Lab Environment

Training environment: TryHackMe cybersecurity lab.

Access method: AttackBox or VPN, according to the room instructions.

Testing focus: client-side source inspection and application input handling.

Target functionality examined: Employee Directory search and Support Board.

4. Reconnaissance & Identification of Injection Points

The client-side source code was inspected to understand the application's input handling and identify useful information for the lab. Two potential locations were identified:

Employee Directory search functionality.

Support Board, where submitted messages are stored and displayed.

5. Employee Directory Testing Testing initially focused on the Employee Directory search functionality. A basic script payload was attempted first. The payload did not produce the expected alert, so additional variations were considered. Since the search functionality did not provide a successful result, testing was moved to the second identified location.

6. Support Board Testing The Support Board was a more promising injection point because submitted messages were stored and subsequently rendered in the community thread. A payload using an image element and an error event was tested. When the image failed to load, the event handler triggered the JavaScript alert used by the lab. <img src='1' onerror/=alert(0) />

7. Successful Stored XSS After the payload was submitted to the Support Board, the application processed the stored content and the XSS test was successfully triggered. This confirmed that the Support Board could be used to demonstrate stored XSS in the lab environment.

Evidence — Captured Flag The screenshot below shows the Support Board result and the flag generated after the successful XSS test.

8. Flag & Result FLAG{STORED_XSS_ACHIEVED}

9. Vulnerability Analysis

10. Security Impact The lab demonstrates the security impact of allowing untrusted input to be rendered as active browser content. In a real application, successful XSS can potentially affect users who view the vulnerable content and may lead to unauthorized actions or exposure of information, depending on the application's security controls and the privileges available to the affected browser session.

11. Recommended Remediation Apply context-appropriate output encoding before rendering untrusted data. Sanitize user-supplied HTML when HTML input is genuinely required. Avoid inserting untrusted content into the DOM as executable HTML. Use a restrictive Content Security Policy (CSP) as an additional defense layer. Validate and handle untrusted input on the server side. Retest all user-controlled input locations after remediation.

12. What I Learned This lab provided practical experience in identifying potential XSS injection points, testing different input locations, recognizing why a basic payload may not succeed, and confirming a stored-XSS condition through a controlled browser-side event. It also highlighted the importance of output encoding, input sanitization, and layered web application defenses.

13. Conclusion The investigation identified two possible input locations and successfully demonstrated stored XSS through the Support Board. The successful payload triggered the expected JavaScript behavior and resulted in the lab flag. The exercise reinforces the need for secure input handling and output encoding whenever user-controlled data is displayed by a web application.