是否有可能通过正确的 JavaScript 字符串转义来利用 JSON 响应？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3146324/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it possible to XSS exploit JSON responses with proper JavaScript string escaping
提问by Chris Mountford
JSON responses can be exploited by overriding Array constructors or if hostile values are not JavaScript string-escaped.
JSON 响应可以通过覆盖 Array 构造函数或恶意值不是 JavaScript 字符串转义来利用。
Let's assume both of those vectors are addressed in the normal way. Google famously traps JSON response direct sourcing by prefixing all JSON with something like:
让我们假设这两个向量都以正常方式寻址。谷歌通过在所有 JSON 前面加上类似的前缀来捕获 JSON 响应直接来源，这是著名的：
throw 1; < don't be evil' >
And then the rest of the JSON follows. So Dr. Evil cannot, using the sort of exploit discussed here http://sla.ckers.org/forum/read.php?2,25788get your cookie (assuming you're logged in) by putting the following on his site:
然后是 JSON 的其余部分。因此，邪恶博士无法使用此处讨论的那种漏洞利用http://sla.ckers.org/forum/read.php?2,25788通过将以下内容放在他的网站上来获取您的 cookie（假设您已登录） ：
<script src="http://yourbank.com/accountStatus.json">
As for string escaping rules, well if we're using double quotes, we need to prefix each with a backslash and each backslash with another backslash etc.
至于字符串转义规则，如果我们使用双引号，我们需要在每个前加上一个反斜杠，每个反斜杠加上另一个反斜杠等等。
But my question is, what if you're doing all of this?
但我的问题是，如果你正在做这一切呢？
Burpsuite (the automated security tool) detects embedded XSS attempts that are returned unHTML-escaped in a JSON response and it reports it as an XSS vulnerability. I have a report that my application contains vulnerabilities of this kind but I am not convinced. I've tried it and I can't make an exploit work.
Burpsuite（自动化安全工具）检测嵌入的 XSS 尝试，这些尝试在 JSON 响应中返回非 HTML 转义，并将其报告为 XSS 漏洞。我有一份报告说我的应用程序包含此类漏洞，但我不相信。我已经尝试过了，但我无法使漏洞利用工作。
So I don't think this is correct, but I ask you StackOverflow community, to weigh in.
所以我不认为这是正确的，但我请你 StackOverflow 社区，权衡。
There is one specific case, that of IE MIME-type sniffing that I think could result in an exploit. After all, IE 7 still had the "feature" that script tags embedded in image comments were executed regardless of the Content-Type header. Let's also leave such clearly stupid behaviour aside at first.
有一种特殊情况，我认为可能会导致漏洞利用的 IE MIME 类型嗅探。毕竟，IE 7 仍然具有嵌入在图像注释中的脚本标签的“功能”，无论 Content-Type 标头如何。让我们先把这种明显愚蠢的行为放在一边。
Surely the JSON would be parsed by either the native JavaScript parser (Window.JSON in Firefox) or by an eval() as per the old default jQuery behaviour. In neither case would the following expression result in the alert being executed:
当然，JSON 将由原生 JavaScript 解析器（Firefox 中的 Window.JSON）或 eval() 解析，按照旧的默认 jQuery 行为。在这两种情况下，以下表达式都不会导致执行警报：
{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}
Am I right or am I wrong?
我是对还是错？
采纳答案by Chris Mountford
For the record, although I accepted an answer, for the exact literal question I am asking, I was right and there was no vulnerability due to the presence of non-HTML-escaped yet correctly JSON-escaped HTML inside JSON values. There could be a bug there if that value was inserted into the DOM without client-side escaping but Burpsuite has little chance of knowing if that would happen just by looking at network traffic.
作为记录，虽然我接受了一个答案，但对于我所问的确切字面问题，我是对的，并且由于在 JSON 值中存在非 HTML 转义但正确 JSON 转义的 HTML，因此没有漏洞。如果在没有客户端转义的情况下将该值插入到 DOM 中，则可能存在错误，但 Burpsuite 几乎没有机会通过查看网络流量来知道这是否会发生。
In the general case of determining what is a security vulnerability in these circumstances, it's instructive to recognise that while it may not feel like good design, the response content of a JSON value could legitimately be known to certainly contain no user input and be intended to be already rendered HTML to be safely inserted in the DOM unescaped. Escaping it would be a (non-security) bug as I mentioned in another comment.
在确定在这些情况下什么是安全漏洞的一般情况下，认识到虽然它可能不是一个好的设计，但可以合法地知道 JSON 值的响应内容肯定不包含用户输入并且旨在已经呈现的 HTML 可以安全地插入到未转义的 DOM 中。正如我在另一条评论中提到的那样，逃避它将是一个（非安全性）错误。
回答by rook
This potential xss vulnerability can be avoided by using the correct Content-Type. Based on RFC-4627all JSON responses should use the application/jsontype. The following code is not vulnerableto xss, go ahead test it:
这种潜在的 xss 漏洞可以通过使用正确的Content-Type. 基于RFC-4627，所有 JSON 响应都应使用该application/json类型。以下代码不易受 xss攻击，请继续测试：
<?php
header('Content-type: application/json');
header("x-content-type-options: nosniff");
print $_GET['json'];
?>
The nosniffheader is used to disable content-sniffing on old versions of Internet Explorer. Another variant is as follows:
该nosniff头被用来将禁用内容嗅探旧版本的Internet Explorer。另一种变体如下：
<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>
when the above code is viewed by a browser the user was prompted to download a JSON file, the JavaScript was not executed on modern versions of Chrome, FireFox and Internet Explorer.This would be an RFC violation.
当浏览器查看上述代码时，系统提示用户下载 JSON 文件， 但 JavaScript 并未在现代版本的 Chrome、FireFox 和 Internet Explorer 上执行。这将违反 RFC。
If you use JavaScript to eval()the JSON above or write the response to the page then it becomes DOM Based XSS. DOM based XSS is patched on the client by sanitizing the JSON before acting on this data.
如果你eval()对上面的 JSON使用 JavaScript或将响应写入页面，那么它就变成了DOM Based XSS。基于 DOM 的 XSS 在客户端上通过在处理此数据之前清理 JSON 来修补。
回答by Alexey Lebedev
Burpsuite (the automated security tool) detects embedded XSS attempts that are returned unHTML-escaped in a JSON response and it reports it as an XSS vulnerability.
Burpsuite（自动化安全工具）检测嵌入的 XSS 尝试，这些尝试在 JSON 响应中返回非 HTML 转义，并将其报告为 XSS 漏洞。
Maybe it tries to prevent the vulnerability described in the rule 3.1 of OWASP XSS Cheat Sheet.
也许它试图防止OWASP XSS Cheat Sheet 规则 3.1 中描述的漏洞。
They give the following example of vulnerable code:
他们给出了以下易受攻击的代码示例：
<script>
var initData = <%= data.to_json %>;
</script>
Even if double quotes, slashes and newlines are properly escaped, you can break out of JSON if it's embedded in HTML:
即使双引号、斜线和换行符被正确转义，如果 JSON 嵌入在 HTML 中，您也可以突破它：
<script>
var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>
to_json()function can prevent this issue by prefixing each slash with a backslash. If JSON is used in HTML attribute, the whole JSON string must be HTML-escaped. If it's used in a href="javascript:"attribute, it must be URL-escaped.
to_json()函数可以通过在每个斜杠前面加上反斜杠来防止这个问题。如果在 HTML 属性中使用 JSON，则整个 JSON 字符串必须是 HTML 转义的。如果在href="javascript:"属性中使用它，则它必须是 URL 转义的。
回答by anon
If we limit our scope to IE (all versions), assume you are running a site based on PHP or ASP.NET, and ignore the IE anti-xss filter, then you are wrong: your users are vulnerable. Setting 'Content-type: application/json' will not help, either.
如果我们将范围限制在 IE（所有版本），假设您正在运行基于 PHP 或 ASP.NET 的站点，而忽略 IE 反 xss 过滤器，那么您就错了：您的用户容易受到攻击。设置 'Content-type: application/json' 也无济于事。
This is due to (as you mention) IE's content detection behavior, which goes beyond sniffing for HTML tags in the response body to include URI analysis.
这是由于（正如您所提到的）IE 的内容检测行为，它超越了在响应正文中嗅探 HTML 标签以包括 URI 分析。
This blog posting explains this very well:
这篇博文很好地解释了这一点：
http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html
