Finding the first XSS
The following image shows the endpoint located in the index, which it’s parameter value is being reflected to the body of the website.
Instead of giving a string value, let’s try inputting an HTML simple payload. I entered <h1>kleiton0x00</h1> and hopefully the payload will be reflected and displayed as a HTML content.
Cool, we have HTML Injection, so let’s try to leverage it into XSS. This time I entered the simplest XSS payload ever: <script>alert(1)</script>
Wait?! It got successfully injected into the website, but no alert 1?!?!? Looking at the page source, nothing was being filtered or removed.
While taking a look at Developer Tools of the browser (Console), I realised that the script is being blocked by Content-Security-Policy.
What does this mean? Content Security Policy (CSP) is an added layer of security, specifically a HTTP Header which blocks external codes to be injected into a website. Usually a well-implemented CSP only allows script by internal entities (the domain itself).
First we have to detect how CSP works and from which source it allows the scripts to be loaded inside the website.
Finding another vulnerable endpoint to XSS
Since we can’t bypass it, I decided to look around, trying to find more XSS. I opened the Page Source of the index, and while scrolling I noticed a php code which has an parameter. Interesting!
Without losing time, I immediately went to /js/countdown.php
In the end parameter, I put a simple string value to see how the website behaves.
Instead of entering a simple string, let’s try to break the js string. How to do this? Based on the code, our reflected input is being added right after the numbers.
Unfortunately there is codes left on the same line: *1000).getTime();
How to get rid of those? Easy, simply by commenting. So, at the end of our input, we add //
Our final payload would be:
So the full URL would be: http://website.com/js/countdown.php?end=2534926825);alert(1);//
When going to the given URL, no XSS is being reflected. Why? Because our XSS is being again blocked by CSP.
Bypassing CSP with 2 XSS using MIME Sniffing
It’s time to combine the first XSS we found on index page and the second XSS we found on the countdown.php.
Let’s see how MIME sniffing can result in a XSS vulnerability. For an attacker to perform an XSS attack by leveraging MIME sniffing, there are certain preconditions that must be fulfilled. Note that, the preconditions are both on client side:
So, combining the XSS payload of the first one with the URL of the vulnerable php file, our final payload will be:
We bypassed CSP and successfully executed our alert(1) code using MIME Sniffing.