Fortify对DataContractJsonSerializer

Question

在C#/.NET项目上运行HP Fortify。从Web源向.NET的DataContractJsonSerializer提供JSON文档的行为触发了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已经有一段时间了。

编辑:引用描述：

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

在本例中，数据在第43行的DownloadString() SF.cs中输入。

1. 数据被写入JSON流。

在本例中，JSON是由ReadObject()在第45行的SF.cs中编写的。

应用程序通常使用JSON存储数据或发送消息。当用于存储数据时，JSON通常被视为缓存的数据，并且可能包含敏感信息。当用于发送消息时，JSON通常与RESTful服务一起使用，并可用于传输诸如身份验证凭据之类的敏感信息。

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

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

1. 例外情况
2. 逻辑操纵
3. XSS或动态评估

第一个是想要的行为--如果JSON格式严重错误，应用程序就会举手停止。#2是可能的，但是如何在不进行解析的情况下验证它呢？#3是不可能的，因为解析逻辑不是JavaScript eval()。

EDIT2:另一个.NET的JSON阅读器，JavaScriptSerializer，不会导致Fortify中的错误。真奇怪。

Answer 1

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

Answer 2

对不起，但我不同意你的评论的观点

->解析的风险在哪里？除非解析器是window.eval() (而不是)，否则就没有风险。如果字符串格式错误，解析器将抛出异常。

这里的实际抱怨不是解析器的直接抱怨，而是传递给解析器的值。您假设正在读取/传递的数据是JSON或非JSON，这将导致异常(如果后者是异常的话)，但是，您忽略了一个要点，即可能存在危险的有效JSON，这可能会影响您的程序逻辑，或者可能导致其他严重的漏洞。

如果你要通过Fortify关于JSON注入的描述，有一个很好的地方是你没有注意到的：

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

因此，在当前代码中，string s = wc.DownloadString(SomeURL);是问题的潜在原因。在将字符串流到内存中之前，您应该检查该字符串的正确性。如上文所述，在严重情况下，可以插入可能影响业务逻辑的无关元素。显然，这就是静态代码分析器可以为您所做的。你知道在这里传递什么数据，但是Fortify不知道/不知道。毕竟是一个静态代码分析器！

因此，如果您希望Fortify不再抱怨，请对字符串进行正常检查，比如测试基于JSON数据的跨站点脚本攻击，等等。如果您确信您的字符串总是干净的，那么您可以禁止此警告。另外，作为补充，我认为(至少对我来说)使用静态代码分析器工具显然会遇到这些问题。