TryHackMe > Web Fundamentals: Cross-site Scripting – Part 2: Reflected + DOM XSS

Understand how cross-site scripting occurs and how to exploit it - Reflected + DOM-based XSS

Disclaimer!!!
The information provided in this blog is to be used for educational purposes only. All of the information in this blog is meant to help the reader to develop a hacker defense attitude in order to prevent the attacks discussed. In no way should you use the information to cause any kind of damage. Hacking is a crime and I am not responsible for the way you use it.

Welcome to the second part which is all about reflected and DOM XSS. Enjoy!

Task 4: Reflected XSS

Reflected XSS is the most common type of XSS attack. The malicious payload is part of the victims request to the website and the website includes this payload in response back to the user. To summarize, an attacker needs to trick a victim into clicking a URL to execute their malicious payload.

This might seem harmless as it requires the victim to send a request containing the attacker’s payload, and a user wouldn’t attack themselves. However, attackers could trick the user into clicking their crafted link that contains their payload via social-engineering them via email…

The following screenshot illustrates the attack:

https://tryhackme.com/room/xss

The attacker crafts a URL containing a malicious payload and sends it to the victim. The victim is tricked by the attacker into clicking the URL. The request could be: http://example.com/search?keyword=<script>…</script>

The website then includes this malicious payload from the request in the response to the user. The victim’s browser will execute the payload inside the response. The data the script gathered is then sent back to the attacker (it might not necessarily be sent from the victim, but to another website where the attacker then gathers this data – this protects the attacker from directly receiving the victim’s data).

Exploitation time! Navigate to the ‚Reflected XSS‘ page on the XSS Playground:

You can see that there are 2 challenges. We will resolve them one by one as usual:

  1. Craft a reflected XSS payload that will cause a pop-up saying „Hello“.
  2. Craft a reflected XSS payload that will cause a pop-up with your machine’s IP address
  1. From the previous post, we know that we have to use alert() box to display whatever we want. The code should look like the following:
http://10.10.233.157/reflected?keyword=<script>alert(“Hello”)</script>

Here, http://10.10.233.157/reflected is a webpage that is vulnerable to XSS. We are using webpage’s parameter named keyword and assigning a malicious XSS payload into it. And once you open this link, the code gets processed and the „Hello“ message is displayed:

2. As I am a complete beginner in Javascript, I had to google a bit. After a while, I found that we need to use window.location object and ask for a hostname, like the following:

<script>alert(window.location.hostname)</script>

But as this is Reflected XSS attack, we need to pass this to a URL that will include this payload:

http://10.10.233.157/reflected?keyword=<script>alert(window.location.hostname)</script>

And when we load the page…

…you can see that our malicious code gets executed.

Task 5: DOM-Based XSS

DOM stands for Document Object Model and is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style and content.

In a DOM-based XSS attack, a malicious payload is not actually parsed by the victim’s browser until the website’s legitimate JavaScript is executed. So what does this mean?

With reflective xss, an attacker’s payload will be injected directly on the website and will not matter when other Javascript on the site gets loaded. Look at the following example:

<html>
You searched for <em><script>...</script></em>
</html

Here, whenever someone loads the page that contains this, the code gets executed by user’s browser no matter what.

DOM-Based XSS is a bit different. With DOM-Based XSS, an attacker’s payload will only get executed if the vulnerable Javascript code is either loaded or interacted with. It goes through a Javascript function like so:

var keyword = document.querySelector('#search')
keyword.innerHTML <script>...</script>

Let’s see this in practice to understand.

There are two tasks for us:

  1. We need to find a way to execute an alert with our cookie value. The hint tells us to try executing the following first:
<script>test" onmouseover="alert('Hover over the image and inspect the image element')"</script>

After doing so, nothing happens. But when we hover over the image…

Our Javascript code gets executed! Now we just need to replace our test message with cookie value. It’s as simple as:

<script>test" onmouseover="alert(document.cookie)"</script>

2. We need to create an onhover event on an image tag, that change the background color of the website to red. Hint tells us what code we need to use for that (or you could simply google that):

document.body.style.backgroundColor = "red"

Now put it in our payload:

test" onmouseover="document.body.style.backgroundColor = 'red';

Tada, we changed the appearance of the page with the help of DOM-Based XSS.

Task 6: Using XSS for IP and Port Scanning

Here, I will not stick to TryHackMe cause the info is not sufficient. We have to look for more info on our own. Here is what I found:

As an attacker, you are outside the target network. Perhaps, you can only see/interact with external IP addresses but you cannot access the internal network. You have no access there. Or have you?

On the application layer your browser has no notion of internal and external IP addresses. So any website is able to tell your browser to request a resource from your internal network. It means that if you can get a target users to browse to any website that has an XSS flaw, using XSS attacks you can have Javascript code (eg. IP scanner) run inside their users‘ browser on their users‘ workstation (which is in the internal network). This way, victims could launch a port scan of their own internal network.

At a high level, it’s super simple. You just need to make an HTTP request to the IPs and ports that you want. You can do that by creating html image tags (img) that have a url (src) of http://IP:port/something.jpg

So find a website vulnerable to XSS and inject malicious Javascript code you want the victim to run into a website (eg. <img src=“http://192.168.0.1/favicon.ico“ onload=“alert(‚Found‘)“ onerror=“alert(‚Not found‘)“>). Then send a link to the website to the victim via email. The victim opens the email, the vulnerable site loads, and the Javascript you injected runs on that victim’s browser.

But note that most of apps won’t reply to malformed packets and all major browsers now block http requests to well known ports (like 22-ssh, etc.) so those will always be reported as closed via this method.

Task 7: XSS Keylogger

Javascript can be used for many things, including creating an event to listen for keypresses.

For some more examples of XSS payloads, visit https://github.com/payloadbox/xss-payload-list

See you!

All credits go to tryhackme (https://tryhackme.com/p/tryhackme) who has created this excellent room. You can find it at https://tryhackme.com/room/xss

One comment

  1. Its such as you learn my mind! You appear to understand a lot about this, such as you wrote the ebook in it or something. I believe that you just could do with a few to pressure the message home a bit, but instead of that, that is great blog. A fantastic read. I will definitely be back.

Leave a Reply

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *