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

撰写本文的主要重点是，如果Content-type设置为JSON，是否会发生XSS！

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.

在继续之前，我想定义JSON： JavaScript对象表示法(JSON)是一种基于文本的简单数据传输格式，用于在服务器和客户端之间传输数据，这是AJAX应用程序中的一种有效传输机制。

Before jumping into the topic the main areas involved are:

在进入本主题之前，涉及的主要领域是：

MIME嗅探 (MIME Sniffing)

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.

MIME代表“多用途Internet邮件扩展”。 MIME最初定义为支持电子邮件中的非ASCII文本和非文本二进制文件。 但是，在MIME标准中定义的内容类型也用于HTTP协议中，以定义请求或响应中的内容类型。

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

浏览器通常通过观察HTTP响应中的Content-Type响应标头来识别资源的MIME类型。

“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.

浏览器采用“ MIME嗅探 ”，通过检查响应的内容而不是依靠Content-Type标头来确定Web资源的有效MIME类型。 MIME嗅探仅在特定条件下执行，并且嗅探算法因浏览器而异。

X内容类型选项 (X-Content-Type-Options)

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.

X内容类型选项(XCTO) 是与安全相关的HTTP响应标头，服务器使用它来指示浏览器不执行MIME嗅探。 用于此标头的唯一指令是nosniff 。 当开发人员确定Content-Type标头中的MIME类型适合响应的内容时，应使用此标头。

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

使用MIME嗅探进行跨站点脚本编写(适用于旧的浏览器版本)

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.

XCTO标头主要在两个解析上下文中有用：JavaScript和CSS。 这是因为在这些情况下，可以执行客户端代码。 攻击者诱使的客户端代码执行可能会导致跨站点脚本(XSS)漏洞。

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

与MIME嗅探相关JavaScript和CSS解析上下文的示例包括：

• <script> tags

  <script>标签

• <link> tags

  <link>标签

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.

现在，让我们看看MIME嗅探如何导致XSS漏洞。 要使攻击者利用MIME嗅探进行XSS攻击，需要满足一些先决条件。

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.
  攻击者应该能够在服务器端控制响应的内容，以便可以注入恶意JavaScript(客户端)。
• The attacker should be able to introduce an executable context via HTML injection.
  攻击者应该能够通过HTML注入引入可执行上下文。

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.

  如果服务器提供的资源不正确，则攻击将成功。 例如，开发人员在包含文本文件的响应中将text / javascript设置为Content-Type标头的值。

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

  服务器正确表示资源。 但是，浏览器的MIME嗅探机制使资源“可执行”。 例如，开发人员在包含文本文件的响应中将text / plain设置为Content-Type标头的值。 尽管text / plain是文本响应的正确Content-Type ，但是浏览器执行MIME嗅探，使攻击者可以从文本文件执行恶意JavaScript。

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:

一旦满足了这些先决条件，攻击者就可以使用HTML注入来注入可执行上下文，然后将源指定为攻击者控制的资源。 漏洞利用有效负载示例如下：

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

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

一旦浏览器遇到此有效负载，它可能会尝试将test.com的响应解析为JavaScript。 如前所述，MIME嗅探算法因浏览器而异，因此有必要创建概念证明来确认浏览器的行为和漏洞的可利用性。

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.

在这一点上，您中的有些人可能会想知道，利用XSS漏洞不需要MIME嗅探或错误表示的资源。 攻击者可以将远程托管的恶意JavaScript指定为脚本标记的来源，以利用此漏洞。 是的，你是对的。 但是，在某些情况下，浏览器的MIME嗅探行为可能是利用XSS漏洞的唯一方法。

如果存在CSP怎么办？ (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:

假设test.com部署了内容安全策略(CSP)，通过禁止来自远程主机的脚本来缓解XSS漏洞。 此类CSP的示例为：

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

内容安全策略：default-src'self'; img-src https://www.test.com; 脚本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.

在这种情况下，攻击者无法通过使用嵌入式JavaScript或远程托管JavaScript利用XSS漏洞，因为有效负载将被CSP阻止。 但是，攻击者可以利用test.com上托管的资源和MIME嗅探来绕过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.

假设攻击者可以在test.com上上传文本文件。 攻击者可以在文本文件中编写恶意JavaScript，并将该文本文件指定为脚本标记的源。

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

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

即使服务器将Content-Type响应标头设置为text / plain ，浏览器也可以MIME嗅探该响应并将文本文件内容解析为JavaScript。 在这种情况下，CSP无法减轻攻击，因为test.com是列入白名单的域。

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.

在上述情况下，如果开发人员部署XCTO标头并指定Content-Type响应标头的正确值，则可以缓解XSS攻击。

演示JSON XSS的示例： (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.

这是存储的XSS场景，当内容类型设置为JSON和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.

开发人员应始终确保Web应用程序提供的所有资源都具有正确的Content-Type标头值作为响应。 另外，应将具有nosniff指令的X-Content-Type-Options标头部署到所有应用程序响应中。 应该实施适当的编码机制以防止XSS。

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

最后的结论是，在现代浏览器中将content-type设置为application / json时，将无法使用XSS。

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

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