6

我浏览了很多帖子，但未能成功确定如何摆脱来自我的 asmx Web 服务的响应中的讨厌的 d，如 {"d":{"Response":"OK","Auth -键":"JKPYZFZU"}}。

这是由我的类“public Dictionary UserDevice”通过返回 Dictionary 对象创建的。

如果该死的东西不把它全部放入 d 对象中，我会非常高兴！

4

2 回答 2

9

基本上 JSON 数组表示法['hello']本身就是有效的 JavaScript，而 JSON 对象表示法{'d': ['hello'] }本身不是有效的 JavaScript。这样做的结果是数组表示法是可执行的，这开启了 XSS 攻击的可能性。默认情况下将数据包装在对象中有助于防止这种情况发生。

您可以阅读更多关于它为什么存在于戴夫·沃德的帖子. （编辑：正如@user1334007 所指出的，Chrome 现在将此站点标记为不安全）

戴夫·里德（Dave Reed）对该文章的评论尤其具有启发性：

它是一种很容易被误解的安全功能。在您的示例中，保护并不是真正防止意外执行警报。尽管这是 'd' 的一个好处，但在评估 JSON 以将其转换为对象时，您仍然需要担心这一点。

它所做的是防止 JSON 响应因 XSS 攻击而被大规模执行。在这样的攻击中，攻击者可以插入一个调用 JSON Web 服务的脚本元素，甚至是在不同域中的一个，因为脚本标签支持这一点。而且，由于它毕竟是一个脚本标签，如果响应看起来像 javascript，它将作为 javascript 执行。相同的 XSS 攻击可以重载对象或数组构造函数（以及其他可能性），从而从其他域访问该 JSON 数据。

要成功实现这一目标，您需要 (1) 一个 xss 易受攻击的站点 (good.com) — 任何站点都可以，(2) 一个 JSON 网络服务，它在 GET 请求中返回所需的有效负载（例如 bank.com/getaccounts）， (3) 当人们访问 good.com 时，将您从 bank.com 捕获的数据发送到一个邪恶的位置 (evil.com)，(4) 恰好登录到 bank.com 的 good.com 的不幸访问者使用相同的浏览器会话。

保护您的 JSON 服务不返回有效的 javascript 只是您可以做的一件事来防止这种情况发生。禁止 GET 是另一个（脚本标签总是做 GET）。要求某个 HTTP 标头是另一个（脚本标签不能设置自定义标头或值）。ASP.NET AJAX 中的 Web 服务堆栈完成了所有这些工作。任何创建自己的堆栈的人都应该小心地做同样的事情。

于 2010-08-05T19:02:22.890 回答
1

您可能正在使用某种框架，该框架会使用 d 元素自动包装您的 Web 服务 json 响应。

我知道微软的 JSON 序列化程序在服务器端添加了 d ，反序列化 JSON 字符串的客户端 AJAX 代码期望它存在。
我认为 jQuery 也可以这样工作。

您可以在Rick Strahl 的博客上阅读更多相关信息

还有一种方法可以让您使用WCF“原始”编程模型返回纯 json（不带 'd'​​ 元素）。

于 2010-08-05T18:47:32.090 回答