Basically Cross-Site scripting is injecting the malicious code into the websites on the client-side. This vulnerability normally allows an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform and access any of the user’s data.

The main focus of writing this article is whether XSS happens if the Content-type is set to JSON!!!!!

Before I go further, I want to define JSON: JavaScript Object Notation (JSON) is a simple, text-based data transfer format that is used to transmit data between a server and a client, an efficient transport mechanism in AJAX applications.

Before jumping into the topic the main areas involved are:

MIME Sniffing

Browsers usually identify a resource’s MIME type by observing the Content-Type response header in an HTTP response.

MIME sniffing” is adopted by browsers to determine the effective MIME type of a web resource by examining the content of the response instead of relying on the Content-Type header. MIME sniffing is performed only under specific conditions and algorithms for sniffing vary by browser.

X-Content-Type-Options

Cross-Site Scripting Using MIME Sniffing(Applicable in old browser versions)

The XCTO header is mainly useful in two parsing contexts: JavaScript and CSS. This is because, in these contexts, client-side code execution is possible. An attacker-induced client-side code execution might result in a Cross-Site Scripting (XSS) vulnerability.

Examples of JavaScript and CSS parsing contexts relevant to MIME sniffing are:

  • <script> tags
  • <link> tags

Now, let’s see how MIME sniffing can result in an XSS vulnerability. For an attacker to perform an XSS attack by leveraging MIME sniffing, there are certain preconditions.

Preconditions on client-side (both necessary for successful exploitation):

  • The attacker should be able to control the content of the response in the server-side so that malicious JavaScript(client-side)can be injected.
  • The attacker should be able to introduce an executable context via HTML injection.

Preconditions on the server-side (only one necessary for successful exploitation):

  • If the server misrepresents a resource, the attack will be successful. For example, the developer sets text/javascript as the value of the Content-Type header in a response containing a text file.
  • The server represents a resource correctly. However, the browser’s MIME sniffing mechanism makes the resource “executable”. For example, the developer sets text/plain as the value of the Content-Type header in a response containing text file. Although text/plain is the correct Content-Type for a text response, the browser performs MIME sniffing and makes it possible for an attacker to execute malicious JavaScript from the text file.

Once these preconditions are satisfied, the attacker can use HTML injection to inject executable context and then specify the source as the attacker-controlled resource. An example exploit payload is as follows:

<script src=”https://www.test.com/attacker_file”></script>

Once this payload is encountered by the browser, it may try to parse the response from test.com as JavaScript. As stated before, MIME sniffing algorithms vary by browser, and hence it is necessary to create a proof of concept to confirm the behavior of a browser and exploitability of the vulnerability.

At this point, some of you may be wondering that MIME sniffing or a misrepresented resource is not necessary to exploit an XSS vulnerability. An attacker can specify a remotely hosted malicious JavaScript as the source of the script tag to exploit the vulnerability. Yes, you are correct. However, there is one case where the MIME sniffing behavior of a browser might be the only way to exploit an XSS vulnerability.

What if CSP is Present?

Content-Security-Policy: default-src ‘self’; img-src https://www.test.com; script-src https://www.test.com

In this case, an attacker cannot exploit an XSS vulnerability by using inline JavaScript or remotely hosted JavaScript because the payload will be blocked by CSP. However, an attacker can make use of a resource hosted on test.com and MIME sniffing to bypass CSP.

Let’s assume that an attacker can upload text files on test.com. The attacker can write malicious JavaScript in a text file and specify the text file as the source of a script tag.

<script src=”https://www.test.com/attacker_malicious_file.txt” ></script>

Even if the server sets the Content-Type response header as text/plain, a browser may MIME sniff the response and parse the text file content as JavaScript. CSP will not mitigate an attack in this case because test.com is a whitelisted domain.

In the above scenarios, if the developers deploy the XCTO header and specify the correct value of the Content-Type response header, the XSS attack can be mitigated.

An example demonstrating JSON XSS:

Code snippet which shows values being retrieved from the database and shown in the browser with text/html content-type.
The browser executing the script present in the “name” field.
Code snippet which shows values being retrieved from the database and shown in the browser with application/json content-type.
The Browser response which shows the payload not being executed as the Content-type is application/json.

What Should Developers Do?

A final conclusion would be XSS will not be possible when content-type is set to application/json in modern browsers.

References:

https://security.stackexchange.com/questions/150009/reflected-xss-via-json-executed-with-burp-but-how-to-do-it-in-realistic-conditi

Hungry for knowledge in Security

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