Physuru's Blog

Intigriti's May 2020 XSS Challenge

Intigriti's May 2020 XSS challenge

Upon visiting, I was greeted by the following page:

The very first thing that I saw was the bold text, stating that the XSS only works in Firefox (which happens to be my main browser). With that in mind, I pressed CTRL+U to view the page's static HTML. Here's a screenshot of that:

The following HTML was the only reference to JavaScript (of course, excluding the visible text) in the page:
<script async src="widgets.js" charset="utf-8"></script>
I had a look at widgets.js and, at first glance, I saw a minified JavaScript file with some references to Twitter. Upon further inspection, I realised that it was probably a copy & paste of I diff'd the files, and yup - they were basically the same. At that point, I assumed that the code inside widgets.js was safe.

Despite one of the list entries stating that the XSS "should be executed on this page", I decided to look around for other files.

I visited to check if there was anything interesting. I did get new information, but not in the form I was expecting. It responded with the exact same page as before. This meant that the target page was accessible from other paths, which was absolutely useful to know.

Next, I went to and it yielded the following result:

So, what happened here? Well, the exact same HTML was being served, but because the URL's path component included an unescaped /, the browser treated a/ as a directory, and tried to load relative subresources from there. In other words, the browser was attempting to load /a/style.css and /a/widgets.js instead of /style.css and /widgets.js. (By the way, the actual name for this is RelativePathOverwrite.) Progress!

I can't remember exactly how I discovered this - I was likely playing around with the path - but I found an open redirect at<location> very shortly after finding the RPO. For example, redirects to Additionally, visiting (with nothing after the two slashes) didn't redirect, but instead loaded the default page. Now, my objective was clear. I had to make the web browser attempt to load a widgets.js file from my website using both the RPO and the open redirect.

The obvious next (and last) step was path traversal. I did get stuck on this part for a while. I found the difference between Firefox and (most) other browsers fairly quickly, but I didn't know how to apply it. The difference being that, in Firefox, the two dots (..), and the prior path component, don't get removed if the following conditions are met:
- The dots are at the very end of the path, and:
- At least one of those dots is percent-encoded.

For example, if you were to load any (reasonable) variant of (in Firefox), the trailing dots (and the prior path component) would remain.

For some time, I couldn't find a use for this behaviour. However, I knew that this was required to solve the challenge - it resembles path traversal, isn't reproducable on Chrome, and has a Bugzilla thread.

It eventually occurred to me that it may be possible to have the trailing dots resolved by the server. The same idea of trailing dots remaining if one is percent-encoded is also true for single dots. I checked what happens upon visiting - as expected, I get the default page back. Immediately after, I realised that I'd get that back anyway - the web server seems to serve that page in most scenarios. I then tried I got nginx's "Bad Request" page, as opposed to the page that became familiar to me throughout this challenge. This meant that the trailing dots were indeed interpreted specially by the server.

Shortly after, I loaded I was thrilled to see that, instead of being redirected to https://a, I got the default page returned! This meant that the server believed that I was requesting In other words, the server saw the a/, but it then saw the .%2E. The .%2E was resolved to .., meaning that the entire a/.%2E part of the URL was basically just ignored (and thus wouldn't redirect - the server would respond with the default page instead). This was an awesome discovery. Due to the path traversal only being server-side, the browser would still treat //a as the directory from which relative subresources should be loaded! See where this is going? So, the browser then makes a request to //a/widgets.js (for example) which does get redirected (to https://a/widgets.js). To recap: the server returned the same as it would if I were to request //, but to the browser, I was still on //a/.%2E. This caused the same default page to show up, but because the browser now loads resources from //a (which redirects), I knew that with some slight modification to the URL, I'd be able to make widgets.js point to arbitrary JavaScript.

With this knowledge, actually solving the challenge was simple. I had to change a to a location that I controlled. My solution was


My solution was
It works because there's an open redirect at<location>, which can be used alongside an RPO and (server-side) path traversal to make widgets.js "point to" arbitrary JavaScript.