Following the succes of our first XSS challenge, we decided to treat our Twitter followers for another game of “spot the cross-site scripting vulnerability”:
Newly joined intigriti community member Bincup has got luck on his side and got randomly picked as the winner of the challenge. Congratulations, Bincup!
A challenge like this is like a box of chocolates: you never know what you’re gonna get. While we created this challenge with one intended solution, our community found three ways to do the job. This once again highlights the strength in numbers that define bug bounty platforms: the more brains that look at your code, the more bugs might come out.
After the challenge was over, we encouraged people to share their solutions online so others could learn from them. We’ve listed some of the best writeups we’ve seen so far below:
@dee__see injected his payload in a malformed content-type header:
Last but not least, @karouf went the extra mile and found both solutions:
A third and unexpected solution came from 0xNear and dkasak, who found the only self-containing solution without the use of any external resources:
Granted, we didn’t expect this one coming. It seems like our server was treating semicolons as a delimiter according to the obsolete RFC2396. This resulted in the delimited part of the URL, containing the base64 string, being ignored in the XHR request, causing a 200 OK status code, bypassing the check that verifies whether the image exists.
Last but not least, the most creative solution was raised by @mathias, who proposed to buy a TLD (like .com or .me) instead of using decimal or hexadecimal encoded IP addresses. Technically, there is nothing that withholds a TLD owner to host files at the root domain. While this wouldn’t be the cheapest or fastest solution, it’s is the shortest one:
For those who don’t like to read, YouTuber @GoatSniff released a video walkthrough that provides an excellent step-by-step tutorial in how to solve challenges like these:
Five tips were tweeted during this challenge:
- There are two solutions! (this turned out to be wrong)
- Try the unsecure version (for the first and second solution to work, you’d need to load the challenge over http instead of https)
- Hexternal resources could help you. (the first and second solution required an external IP address, in their hexadecimal or decimal notation)
- Read the specs and add some padding (in order to get the base64 payload to work, you sometimes had to add some padding to ensure proper decoding)
- ;, hinting at the unintended solutions by 0xNear and dkasak
Thanks to the community for participating in the challenge and congratulations to the 90 researchers who solved the challenge. A shout-out to the winner Bincup, who won a Burp License, swag package and private invites on our platform.
Didn’t win this time? Keep your head up! We’ll be launching more similar challenges on our Twitter account soon.
Got a cool idea for a challenge? Let us know at email@example.com and we might feature your idea in one of our upcoming challenges!