1nfornography

The following is my documentation on PortSwigger’s Academy labs.

End Goal: Perform a cross-site scripting attack that injects a custom tag and automatically alerts document.cookie

This lab appears to assume that you have completed the previous lab. As such, many of the steps to get to our final payload are the same. Here is a quick refresher (for complete documentation refer to my Solution for PortSwigger’s Academy: Reflected XSS into HTML context with most tags and attributes blocked write-up):

1. Search for a random string in the target’s search box and capture the results in BurpSuite
2. Send results to intruder
3. Replace the string with <>, create two payloads between the angle brackets, and paste the tags found on our XSS cheat sheet into the payload list
4. look for 200 responses
5. Repeat with the XSS cheat sheet events pasted into our payload list
6. look for 200 responses
7. Craft the final exploit payload and go to the exploit server

Essentially we were looking for tags and events that the WAF (Web Application Firewall) was not programmed to look for and then using those to store onto our exploit server to call the print() function. As this lab is mostly the same, but with only custom tags available to us, we’ll skip right to our seventh step. Open the exploit server button located at the header of our lab and paste the following payload into the body section between two script tags:

location = 'https://YOUR-LAB-ID.web-security-academy.net/?search=%3Cxss+id%3Dx+onfocus%3Dalert%28document.cookie%29%20tabindex=1%3E#x';

Then replace the “YOUR-LAB-ID” with your ID found in the address bar (make sure this is the ID of the lab’s target page and not the lab’s exploit server).

Now we just store the exploit and then deliver it to our victim.

…and we have solved our lab! So, there you go, you may solve it now. Unless of course you are curious, like me, and want to better understand the payload itself!

What the exploit payload does

We can see the exploit in action with our dev tools.

We created a custom tag with an id of “x”. This tag contains the onfocus event which triggers our alert function. According to PortSwigger:

“The hash at the end of the URL focuses on this element as soon as the page is loaded, causing the ‘alert’ function to be called.”¹

Just like the previous lab, we URL encoded much of the payload to fly under the WAF’s radar. Though we can see that fin above in our dev tools screenshot, I’ve provided the exploit payload decoded below:

<xss id=x onfocus=alert(document.cookie) tabindex=1>#x’;

Notes

I don’t have much to say beyond what I have said in our previous lab. This was really just an iteration on the previous one, but it does show us that it is important to keep digging for exploits even if almost all tags are blocked.

Footnotes

1. PortSwigger Lab Solution ↩︎

---

Filed under: Pentesting,PortSwigger Academy,XSS attack - @ January 5, 2024 8:33 pm