Question

可以通过重写数组构造函数来利用JSON响应，或者如果恶意值不是JavaScript字符串转义，则可以利用它。

让我们假设这两个向量都是以正常方式处理的。谷歌通过在所有JSON前加上类似的东西来捕获JSON响应直接来源：

throw 1; < don't be evil' >

接着是JSON的其余部分。因此，Evil博士不能，使用此处讨论的那种漏洞http://sla.ckers.org/forum/read.php?2,25788通过在他的网站上添加以下内容来获取您的cookie（假设您已登录）：

<script src="http://yourbank.com/accountStatus.json">

至于字符串转义规则，如果我们使用双引号，我们需要在每个前面加上反斜杠，每个反斜杠加上另一个反斜杠等。

但我的问题是，如果你正在做所有这些怎么办？

Burpsuite（自动安全工具）检测在JSON响应中返回unHTML转义的嵌入式XSS尝试，并将其报告为XSS漏洞。我有一份报告说我的应用程序包含此类漏洞，但我不相信。我已经尝试过了，我无法进行漏洞利用。

所以我不认为这是正确的，但我问你StackOverflow社区，要权衡。

有一个特定的案例，即IE MIME类型嗅探，我认为可能导致漏洞利用。毕竟，IE 7仍然具有“功能”，无论Content-Type标头如何，都会执行嵌入在图像注释中的脚本标签。让我们一开始就抛开这种明显愚蠢的行为。

根据旧的默认jQuery行为，JSON将由本机JavaScript解析器（Firefox中的Window.JSON）或eval（）解析。在任何情况下，以下表达式都不会导致执行警报：

{"myJSON": "legit", "someParam": "12345<script>alert(1)</script>"}

我是对还是错了？

Answer 1

使用正确的Content-Type可以避免这种潜在的xss漏洞。根据{{3}}，所有JSON响应都应使用application/json类型。以下代码不易受攻击到xss，请继续测试：

<?php
header('Content-type: application/json'); 
header("x-content-type-options: nosniff");
print $_GET['json'];
?>

nosniff标头用于禁用旧版Internet Explorer上的内容嗅探。另一种变体如下：

<?php
header("Content-Type: application/json");
header("x-content-type-options: nosniff");
print('{"someKey":"<body onload=alert(\'alert(/ThisIsNotXSS/)\')>"}');
?>

当浏览器查看上述代码时，系统会提示用户下载JSON文件，现代版Chrome，FireFox和Internet Explorer上未执行JavaScript。这将是一个RFC冲突。

如果您使用JavaScript eval()上面的JSON或将响应写入页面，则它变为RFC-4627。基于DOM的XSS通过在处理此数据之前清理JSON来修补客户端。

Answer 2

Burpsuite（自动安全工具）检测嵌入式XSS尝试在JSON响应中返回unHTML-escaped并报告它作为XSS漏洞。

也许它会尝试阻止rule 3.1 of OWASP XSS Cheat Sheet中描述的漏洞。

他们给出了以下易受攻击代码的示例：

<script>
    var initData = <%= data.to_json %>;
</script>

即使双引号，斜杠和换行符被正确转义，如果它嵌入HTML中，你也可以打破JSON：

<script>
    var initData = {"foo":"</script><script>alert('XSS')</script>"};
</script>

jsFiddle

to_json()函数可以通过在每个斜杠前加一个反斜杠来阻止此问题。如果在HTML属性中使用JSON，则必须对整个JSON字符串进行HTML转义。如果它在href="javascript:"属性中使用，则必须进行网址转义。

Answer 3

如果我们将范围限制为IE（所有版本），假设您正在运行基于PHP或ASP.NET的站点，并忽略IE反xss过滤器，那么您错了：您的用户容易受到攻击。设置'Content-type：application / json'也无济于事。

这是因为（正如您所提到的）IE的内容检测行为，它不仅仅是对响应正文中的HTML标记进行嗅探以包含URI分析。

这篇博客文章很好地解释了这一点：

http://blog.watchfire.com/wfblog/2011/10/json-based-xss-exploitation.html

Answer 4

记录下来，尽管我接受了答案，但对于我要问的确切字面问题，我是对的，并且由于在JSON值中存在非HTML逸出但正确JSON逸出的HTML，因此没有漏洞。如果在不进行客户端转义的情况下将值插入DOM中，则可能会出现错误，但是Burpsuite几乎没有机会仅通过查看网络流量来知道是否会发生这种情况。

在确定在这种情况下什么是安全漏洞的一般情况下，有启发性的认识是，尽管可能感觉不像是很好的设计，但可以合理地知道JSON值的响应内容肯定不包含用户输入，并且旨在已经呈现HTML，以便安全地插入未转义的DOM中。如我在另一条评论中所述，转义它将是一个（非安全性）错误。

是否有可能XSS利用适当的JavaScript字符串转义来利用JSON响应

4 个答案: