Content-Security-Policy Bypass to perform XSS using MIME sniffing

Kleitonx00
Dec 9, 2020 · 5 min read

Summary

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

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.

Image for post
Image for post

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.

Image for post
Image for post

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.

Image for post
Image for post

Wait?! It got successfully injected into the website, but no alert 1?!?!? Looking at the page source, nothing was being filtered or removed.

Detecting CSP

While taking a look at Developer Tools of the browser (Console), I realised that the script is being blocked by Content-Security-Policy.

Image for post
Image for post

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.

Image for post
Image for post

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.

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!

Image for post
Image for post

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.

Image for post
Image for post

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

Breaking Javascript string to perform the second XSS

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);//

Image for post
Image for post

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.

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:

  • 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>

Image for post
Image for post
can result in a XSS vulnerability. For an attacker to perform an XSS attack by

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

InfoSec Write-ups

A collection of write-ups from the best hackers in the…

Sign up for Infosec Writeups

By InfoSec Write-ups

Newsletter from Infosec Writeups Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Kleitonx00

Written by

Hello, my name is Kleiton and I am an Infosec student. I have been related to cybersecurity for almost 2 years, by self-learning and the will to contribute.

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Kleitonx00

Written by

Hello, my name is Kleiton and I am an Infosec student. I have been related to cybersecurity for almost 2 years, by self-learning and the will to contribute.

InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. In a nutshell, we are the largest InfoSec publication on Medium. Maintained by Hackrew

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store