PortSwigger's "Stored XSS into HTML context with nothing encoded" Walkthrough
This is the first of the two Apprentice level Stored XSS Labs from Portswigger. Before we get started, you’ll need a Portswigger Academy account. This level is completed without Burp Suite, but here’s a blog post to help you set it up for future levels.
After logging in, head over to the lab, located at https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded. You can find this through the Academy learning path list, or linked within the Stored XSS blog post.
Challenge Information
Click the “Access the Lab” button and you will be taken to a temporary website that is created for your account. This will be in format https://<random string here>.web-security-academy.net/.
This is a stored XSS attack. This means that our malicious input (in the form of some script that executes) will be stored or persist in the webserver somehow (database, etc.) and will be shown to us and likely other users, too.
Here’s the website for the lab:
There’s no obvious areas for input on the home page. If we scroll through the blog and click on an individual post (“View Post”), you’ll end up on a URL such as:
https://<random-string>.web-security-academy.net/post?postId=4We see that there’s a comment section:
Lab Solution
Let’s add our own comment:
We don’t know which fields (if any) are vulnerable, so having a way to differentiate between the two (with alert(1) vs alert(2)) might be helpful. We know that there’s no encoding required for this challenge, so we don’t have to be more clever than <script>alert(1)</script>.
The email and website have a specified format, so we will follow that.
Click enter, then go back to the post page:
We’ve got an alert, and with that, we’ve solved the lab. You can scroll down to see that our username field was not vulnerable (and is being displayed as normal text) but our comment field is blank, since it was executed as Javascript. In other words, the comment field was vulnerable.
