Stored XSS into anchor href attribute with double quotes HTML-encoded
The following is my documentation on PortSwigger’s Academy labs.
End Goal: Submit a comment that calls the alert function when the author name is clicked
In our last lab, we called an alert function by injecting our payload into a search bar. Our “end goal” already alluded that we are likely going to take advantage of the comment section, but for best practices, we should always check a website for any input fields for possible vulnerabilities. So, let’s just pretend that and found the comment section organically.
After going through the blog we find our comment section and come across a few fields, one of which encourages us to input a URL. This will be very useful later. For now, we fill it out and see what happens.
We go back to the comment section after we post our comment and see the above. The name we entered became a hyperlink, and what’s more, it led to the site that we entered.
We see that the link is contained in a double quotation, which is proper for a href tag. If the site automatically converts what we input as a link, are we limited to just URLs, or can we input more? What happens if we input script instead? (Spoiler: we solve the lab)
After trying some payloads with JAVA and running into a dead-end I checked the solution on our Lab’s page and found javascript:alert(1) and yes, this obviously solves the lab, but why this payload and not, say onmouseover=’alert(1)’? I suspected that this was because the site’s coder had accounted for this kind of attack, as it is a very common one. Wanting to learn more, I checked out z3ssh3ll’s video about the lab. My suspicions were correct, and according to him javascritpt: works because it is just not a common way to use javascript and developers may not be aware of this. Cazart! All the better for us, as we can finally complete our attack.
We place our payload into the “Website” section and leave a call-to-action comment to entice users to open our payload. Upon posting the comment we’re told that the lab is complete!
Though complete, we still have not seen our payload in action. Heading back to the blog post and checking out our comment, we can by hovering over the link that our browser recognizes the script. Upon clicking it the script is executed.
Qapla’! The payload works and will stay there awaiting an unsuspecting avid xeno-poetry to activate it…
How to accomplish this in Burp Suite
We repeat our steps, but this time, before we post our first comment (the test comment), we open Burp Suite and turn on Intercept.
From there we hit the “Post Comment” in our browser and let Burp Suite do its thing. Once the Intercept has captured our request, we right-click on what we have and “send to repeater”. Turn Intercept off and the comment is posted, but now we can mess with what we have sent to the repeater. Simply replace our comment (at the bottom) with our payload and send away!
And voilà! Our payload works!
Possible prevention methods
Input validation is the first one that comes to mind1. We can do this by ensuring that the user input starts with a safe protocol such as HTTP and HTTPS, so we cannot use JAVA the way we did. Whitelisting our safe protocols (instead of blacklisting the bad ones) will make sure that everything that is not on the list is disallowed. This helps in that it will disallow anything we forgot to blacklist.
Notes
Though a fairly simple exploit, the malicious uses for this became immediately apparent to me. As someone who has been running web pages for fourteen years, I am constantly running into comment spammers trying to use this exact thing for their evil plans. Most of these can be filtered out with a common plugin like Akismet or Jetpack, but every once in a while a comment like this makes its way through. So on top of the prevention methods listed above, strong comment requirements and moderation can help as well.
I used the following resources in this exercise:
- z3nsh3ll
- PortSwigger’s XSS Cheat Sheet
Filed under: Cybersecurity,Pentesting,PortSwigger Academy,XSS attack - @ December 20, 2023 8:46 pm
One thought on “Stored XSS into anchor href attribute with double quotes HTML-encoded”