Question

针对C＃/。NET项目运行HP Fortify。将JSON文档从Web源馈送到.NET的DataContractJsonSerializer的行为触发了Fortify中的“ JSON注入”问题。

以下代码片段会导致它：

WebClient wc = new WebClient();
string s = wc.DownloadString(SomeURL);
using (MemoryStream mst = new MemoryStream(Encoding.UTF8.GetBytes(s)))
    return new DataContractJsonSerializer(typeof(SomeType)).ReadObject(mst) as SomeType;

Fortify像这样反序列化JSON有什么问题？该类已经在.NET中使用了一段时间。

编辑：引用说明：

数据从不受信任的来源进入程序。


在这种情况下，数据在第43行的SF.cs中的DownloadString（）中输入。


数据被写入JSON流。


在这种情况下，JSON由SF.cs中的ReadObject（）在第45行写入。

应用程序通常使用JSON来存储数据或发送消息。什么时候   JSON用于存储数据，通常像缓存数据一样对待，并且可能   可能包含敏感信息。用于发送消息时，   JSON通常与RESTful服务结合使用，并且可以   用于传输敏感信息，例如身份验证   凭据。

如果更改了JSON文档和消息的语义，   应用程序从未经验证的输入构造JSON。在相对   良性案例，攻击者可能会插入无关的元素   导致应用程序在解析JSON时引发异常   文件或要求。在更严重的情况下，例如涉及   JSON注入，攻击者可能能够插入无关的元素   可以对关键业务进行可预测的操纵   JSON文档或请求中的值。在某些情况下，JSON   注入会导致跨站点脚本编写或动态代码评估。

好的，总而言之，恶意JSON带来的风险是：

例外
操纵逻辑
XSS或动态评估

数字1是期望的行为-如果JSON格式严重错误，则应用程序将举起手并停止。＃2是可能的，但是如何在不解析的情况下对此进行验证？＃3是不可能的，因为解析逻辑不是JavaScript eval()。

EDIT2：另一个.NET的JSON阅读器JavaScriptSerializer在Fortify中不会引起任何错误。很奇怪。

Answer 1

检查是否交换了日期，json的数据联系人序列化程序尝试将日期作为Date(...)嵌入式命令而不是iso字符串处理

Answer 2

对不起，但我不同意your comment：

->解析的风险在哪里？除非解析器是window.eval（）（不是），否则没有风险。如果字符串格式错误，则解析器将引发异常。

这里的实际投诉不是直接针对解析器，而是将值传递给解析器。您假设正在读取/传递的数据是否为JSON，如果为JSON，则将导致异常，但是，您缺少一个重要的点，即可能存在危险的有效JSON，这可能会影响程序逻辑，或者导致其他严重漏洞。

如果您要通过Fortify's description about JSON Injection，那么就会发现有一点很重要，您无需注意：

如果更改了JSON文档和消息的语义，应用程序从未经验证的输入构造JSON。在相对良性案例，攻击者可能会插入无关的元素导致应用程序在解析JSON时引发异常文件或要求。在更严重的情况下，例如涉及JSON注入，攻击者可能可以插入无关的内容允许可预测地操纵业务的要素 JSON文档或请求中的关键值。在某些情况下， JSON 注入会导致跨站点脚本编写或动态代码评估。

因此，在您当前的代码中，string s = wc.DownloadString(SomeURL);是造成问题的潜在原因。您应该先检查此字符串s的完整性，然后再将其流式传输到内存中。如上一段所述，在严重的情况下，可以插入会影响业务逻辑的多余元素。显然，这就是静态代码分析器可以为您完成的工作。 您是谁知道将在此处传递哪些数据的信息，但是Fortify却不知道/不知道。 毕竟，Fortify是静态代码分析器！

因此，如果您不希望Fortify进一步抱怨，请对字符串进行完整性检查，例如基于JSON数据测试跨站点脚本攻击等。如果您确定您的字符串将是始终清洁，则可以取消此警告。另外，还有一点，我认为（至少对我而言）使用静态代码分析器工具会遇到这些问题。

Fortify与DataContractJsonSerializer

2 个答案: