Recently, I performed a Cross Site Scripting vulnerability, however a normal XSS payload wasn’t being triggered because CSP was blocking external Javascript code (XSS) being executed. By finding another XSS vulnerability in another endpoint (which again is being blocked by CSP), I managed to combine them together leading into CSP bypassing and trigger XSS using MIME sniffing

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>

If nothing gets filtered or blocked by WAF, we will be able to trigger the Javascript payload.

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.

Looking at the HTTP Headers, specifically Content-Security-Policy: we can see that CSP has a rule to accept scripts from the website itself and it’s directories and subdomains. Looks like we are very limited as we can’t inject our own malicious Javascript.

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.

We see our string (kleiton0x00) being reflected into the source code. Super! We can start begin injecting our javascript code.

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.

Add ); to close the current Javascript code in the 2nd line. The bracked ) will close the variable value and the ; will close the current javascript code in the 2nd line. Because the code is closed, we can add a new Javascript code, which of course is our malicious code, in our case alert(1);

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:

);alert(1);//

Great, based on the source code, we have injected successfully a Javascript code to the directory. We got a second XSS!

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.

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:

• The attacker should be able to control content in the server’s response so that malicious JavaScript can be injected (the second XSS which we found)
• The attacker should be able to introduce an executable context via HTML injection or Javascript Injection (the first XSS which we found)

Our XSS payload will be based on what we found on the first XSS (<script>alert(1)</script>). Instead of executing a Javascript, we will load the URL of countdown.php which is http://website.com/js/countdown.php?end=2534926825);alert(1);//

So, combining the XSS payload of the first one with the URL of the vulnerable php file, our final payload will be:

<script src=’http://website.com/js/countdown.php?end=2534926825);alert(1);//></script>

We bypassed CSP and successfully executed our alert(1) code using MIME Sniffing.