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 jumping into the topic the main areas involved are:
MIME stands for “Multipurpose Internet Mail Extensions.” MIME was originally defined to support non-ASCII text and non-text binaries in email. However, the content types defined in the MIME standard are also used in the HTTP protocol to define the type of content in a request or response.
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 (XCTO) is a security-related HTTP response header used by servers to instruct browsers to not perform MIME sniffing. The only directive used for this header is nosniff. This header should be used by developers when they are sure that the MIME type in the Content-Type header is appropriate for the response’s content.
Cross-Site Scripting Using MIME Sniffing(Applicable in old browser versions)
- <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 introduce an executable context via HTML injection.
Preconditions on the server-side (only one necessary for successful exploitation):
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:
What if CSP is Present?
Let’s assume that test.com deploys a Content Security Policy (CSP) that mitigates XSS exploits by disallowing scripts included from remote hosts. An example of such CSP would be:
<script src=”https://www.test.com/attacker_malicious_file.txt” ></script>
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:
Here is the stored XSS scenario which retrieves the user-related information from the database when the content-type is set to JSON and HTML.
What Should Developers Do?
Developers should always make sure that all resources served by a web application have correct Content-Type header value in response. Also, the X-Content-Type-Options header with nosniff directive should be deployed for all application responses. A proper encoding mechanism should be implemented to prevent XSS.
A final conclusion would be XSS will not be possible when content-type is set to application/json in modern browsers.
Option to unicode escape , and & in JSON output · Issue #3268 · expressjs/express
Dismiss GitHub is home to over 50 million developers working together to host and review code, manage projects, and…