极客观点
项目管理
HarmonyOS
可以通过覆盖 Array 构造函数或者如果敌对值不是 JavaScript 字符串转义来利用 JSON 响应。
让我们假设这两个向量都以正常方式寻址。谷歌通过在所有 JSON 前加上类似以下内容的前缀来捕获 JSON 响应直接来源：
throw 1; < don't be evil' >
然后是 JSON 的其余部分。所以 Dr. Evil 不能，使用 这里 讨论的那种漏洞。通过在他的网站上放置以下内容来获取您的 cookie（假设您已登录）：
<script src="http://yourbank.com/accountStatus.json">
至于字符串转义规则，如果我们使用双引号，我们需要在每个反斜杠前加上一个反斜杠，在每个反斜杠前加上另一个反斜杠等。
但我的问题是，如果你正在做所有这些怎么办？
Burp Suite （自动安全工具）检测在 JSON 响应中返回的未 HTML 转义的嵌入式 XSS 尝试，并将其报告为 XSS 漏洞。我有一份报告说我的应用程序包含此类漏洞，但我不相信。我试过了，但我无法使漏洞发挥作用。
所以我认为这是不正确的。
有一个特定的案例，我认为 IE MIME 类型的嗅探可能会导致漏洞利用。毕竟，IE 7 仍然具有不管 Content-Type 标头如何执行嵌入在图像评论中的脚本标签的“功能”。让我们先把这种明显愚蠢的行为放在一边。
根据旧的默认 jQuery 行为，JSON 肯定会被本机 JavaScript 解析器（Firefox 中的 Window.JSON）或 eval() 。在这两种情况下，以下表达式都不会导致执行警报：
{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}
我是对还是错？
原文由 Chris Mountford 发布，翻译遵循 CC BY-SA 4.0 许可协议
作为记录，虽然我接受了一个答案，但对于我问的确切的字面问题，我是对的，并且由于 JSON 值中存在非 HTML 转义但正确的 JSON 转义 HTML，所以没有漏洞。如果在没有客户端转义的情况下将该值插入到 DOM 中，则可能存在错误，但 Burpsuite 几乎没有机会仅通过查看网络流量就知道是否会发生这种情况。
在确定这些情况下什么是安全漏洞的一般情况下，认识到虽然它可能感觉不是好的设计，但可以合法地知道 JSON 值的响应内容肯定不包含用户输入并且旨在已经呈现的 HTML 可以安全地插入 DOM 中，不会转义。正如我在另一条评论中提到的那样，转义它将是一个（非安全）错误。