DSL-JSON参数走私浅析 | 长亭百川云

0x00 前言

DSL-JSON 是一个为 JVM（Java 虚拟机）平台设计的高性能 JSON 处理库，支持 Java、Android、Scala 和 Kotlin 语言。它被设计为比任何其他 Java JSON 库都快，与最快的二进制 JVM 编解码器性能相当。

在 DSL-JSON 库中，deserialize 方法和 newReader 都与 JSON 数据的反序列化有关。

com.dslplatform.json.DslJson#deserialize可以直接将 JSON 字符串反序列化为指定的 Java 对象类型。这个方法通常用于简单场景，其中 JSON 数据可以直接映射到一个 POJO。
com.dslplatform.json.DslJson#newReader会返回一个 JsonReader 对象，这个对象可以用来反序列化 JSON 数据。使用 JsonReader 提供了更细粒度的控制，允许你逐个处理 JSON 元素，而不是直接映射整个 JSON 文档到一个对象。

下面简单看看具体的JSON解析过程。

0x01 DSL-JSON解析过程

不论是deserialize 还是newReader的方式，在反序列化时，都会先通过 typeLookup 查找与类型对应的 ReadObject 反序列化器。然后调用对应的read方法进行处理：

在tryFindReader方法中，首先会在 readers 映射中查找是否已经存在与 manifest 对应的 ReadObject 反序列化器。如果存在,则直接返回，否则则调用 extractActualType 方法获取 manifest 的实际类型 actualType，这里一般是对自定义类型进行处理：

以HashMap的类型为例，对应的反序列化器为com.dslplatform.json.ObjectConverter，其主要支持以下数据类型：

查看其read方法的调用逻辑，主要是在deserializeMap方法进行处理：

在deserializeMap方法中，首先检查当前的 JSON 标记是否为{(表示映射的开始)。如果不是,则抛出解析异常。如果下一个标记是},则创建一个空的 LinkedHashMap 并返回。否则,创建一个新的 LinkedHashMap 对象 res等待进行内容（key-value）的解析：

首先会调用com.dslplatform.json.JsonReader#readKey方法对键进行解析：

具体的解析逻辑主要在com.dslplatform.json.JsonReader#parseString进行处理，首先检查当前字符是否以"(表示字符串的开始)。如果不是,则抛出解析异常：

然后进入循环流程,从 JSON 数据流中读取字符,并将其复制到 _tmp 数组中。当遇到双引号 "(表示字符串的结束)，并返回复制的字符数。当遇到反斜杠 \(转义字符)时。会先退出循环,进入转义字符处理逻辑：

对于转义字符,会根据后续字符的值进行不同的处理,包括普通转义字符、Unicode等：

对于\x61的场景，DSL-JSON明显是不支持的，会抛出Invalid escape combination detecte异常。

最后返回对应的length，获得当前的键属性。然后调用deserializeObject方法获取对应的值，这里会根据 JSON 值的类型,调用相应的反序列化逻辑,将 JSON 值转换为相应的 Java 对象，例如如果是"开头的话，会调用com.dslplatform.json.JsonReader#readString进行处理,如果均匹配不上，会调用NumberConverter.deserializeNumber当成数字进行处理，整个过程包含了一些错误处理逻辑,确保在遇到非法 JSON 数据时能够正确地抛出异常：

获取完对应的值后，如果此时的标记是逗号 ,,则继续读取下一个键值对,并将其存储到 res 中:

最后检查最后一个标记是否为右大括号},并返回前面填充的解析内容：

以上是DSL-JSON大致的解析过程。

0x02 参数走私场景

在前面的分析过程中，DSL-JSON在调用deserializeMap处理时，会创建一个新的 LinkedHashMap 对象 res对JSON内容的解析结果进行存储：

这里的res数据类型是LinkedHashMap，也就是说，如果在put操作时使用了已存在的键,则新值会替换旧值,原有的键值对会被新的键值对覆盖。默认情况下在反序列化时，会取重复键值的后者。

下面结合JavaWeb中常见的JSON解析库的解析特性，看看其重复键值对情况下潜在的参数走私场景。

2.1 Unicode解码差异

在前面分析的时候提到，在tryFindReader方法中，首先会在 readers 映射中查找是否已经存在与 manifest 对应的 ReadObject 反序列化器。如果存在,则直接返回，否则则调用 extractActualType 方法获取 manifest 的实际类型 actualType。这里获取到的反序列化器的解析方式是有区别的。例如这里指定序列化成自定义的User对象：

DslJson<Object> dslJson = new DslJson<Object>();  
JsonReader<Object> jsonReader = dslJson.newReader(buff);  
User user = jsonReader.next(User.class);

跟进解析过程，可以看到获取到的反序列化器是跟ObjectFormatDescription相关的：

在其bind方法中，会调用bindContent方法对JSON内容进行处理封装：

可以看到当满足WeakHash的匹配时，会调用User类的set方法对对应的属性进行赋值,value的获取是通过com.dslplatform.json.JsonReader#readString对JSON进行处理，实际上还是通过com.dslplatform.json.JsonReader#parseString进行解析：

简单看看ObjectFormatDescription#bindContent的逻辑，看看WeakHash的具体含义。在ObjectFormatDescription#bindContent的逻辑中,首先检查当前的 JSON 标记是否为},如果是,则检查是否有必填属性未被赋值：

否则进入JSON的解析，进入一个循环,遍历所有需要绑定的属性。在循环中,对于每个属性,计算属性名称的WeakHash,并与预计算的WeakHash进行比较。若两者匹配,则进一步比较属性名称是否完全匹配，若匹配则对对应的属性进行赋值，如果下一个标记是逗号,,则继续读取下一个属性。否则,退出循环：

也就是说，WeakHash主要跟反序列化过程中匹配的属性有关。在fillNameWeakHash中，主要是通过calcWeakHash方法来计算Weakhash的，查看具体的计算方式：

在calcWeakHash方法中，首先还是判断是否以"开头，然后进入一个循环,从 JSON 数据流中读取属性名称的字节,并将它们累加到 hash 中：

如果遇到反斜杠\(表示转义字符),则跳过下一个字节
如果遇到双引号 "(表示属性名称的结束),则退出循环
如果读取到数据流的末尾,则调用 calcWeakHashAndCopyName 方法计算最终的哈希值并复制属性名称

这里有一个比较关键的节点是，当遇到反斜杠\时，不会进一步对类似Unicod等字符进行额外的处理，直接跳过下一个字节。那么是否说明当使用这种方式进行JSON解析时，无法识别Unicode编码的key呢？

这里从debug信息可以看到，以属性activity为例，预计算的WeakHash为1050：

若经过Unicode编码处理后，获取到的WeakHash为1269，此时由于两者不一致，导致不会进一步调用对应属性的set方法，设置对应的内容:

也就是说，跟基础类型Map相比，类似User User = jsonReader.next(User.class);自定义类型的解析，DSL-JSON仅仅支持值的Unicode编码，不像fastjson/jackson等也支持Key的Unicode编码。

验证上述的猜想：

对key进行Unicode编码，此时输出的activityId内容为null：

String body = "{\"\\u0061ctivityId\":\"321\"}";  
DslJson<Object> dslJson = new DslJson<Object>();  
JsonReader<Object> jsonReader = dslJson.newReader(buff);  
User user = jsonReader.next(User.class);  
System.out.println(user.getActivityId());

对value进行Unicode变么，此时正常输出activityId内容

String body = "{\"activityId\":\"\\u0033\\u0032\\u0031\"}";  
DslJson<Object> dslJson = new DslJson<Object>();  
JsonReader<Object> jsonReader = dslJson.newReader(buff);  
User user = jsonReader.next(User.class);  
System.out.println(user.getActivityId());

默认情况下，类似重复键值的情况，Jackson/Fastjson等主流的解析器默认会保留最后一个出现的键值对。当相关安全措施（例如鉴权、参数检查等）使用了DSL-JSON进行JSON解析时，若与实际Controller的解析模式不一致，可以考虑结合重复键值+Unicode解码差异的特点来尝试绕过。

例如上面的例子，由于无法识别自定义类型属性key的Unicode编码，对于下面的JSON重复键值内容只能取前者123，而其他解析器则默认获取后者，这里存在解析差异，在特定情况下可以达到参数走私的效果，在日常代码审计过程中需要额外的关注：

{"activityId":"123","\u0061ctivityId":"321"}

2.2 注释符截断

部分JSON解析库支持在JSON中插入注释符，注释符中的任何字符不会被解析。例如gson支持/**/（多行）、//（单行）、#（单行）这三类注释符，Fastjson支持除#以外的注释符等。而**DSL-JSON在自定义类型解析时，对注释符的解析“不敏感”。**在特定的情况下也会存在参数走私的风险。

例如下面的例子：

String body ="{\"test\":1/*,\"activityId\":\"333\",\"test\":*/,\"activityId\":\"321\"}";  
DslJson<Object> dslJson = new DslJson<Object>();  
final byte[] buff = body.getBytes("UTF-8");  
JsonReader<Object> jsonReader = dslJson.newReader(buff);  
User user = jsonReader.next(User.class);  
System.out.println("DSL-JSON parse result:"+user.getActivityId());

最终获取到的内容是注释内的内容：

原因也很简单，因为在计算WeakHash后，类似上面请求的json内容，test并不是是指定类型User的属性，并不会参与解析，经过,分割后，注释内容里的activityId被当成正常JSON内容参与了解析。

对于Fastjson/Gson能支持注释解析的解析器会存在解析差异，存在参数走私的风险：

0x03 其他

此外，部分畸形JSON在DSL-JSON仍可正常解析，例如额外的}并不会又影响JSON的解析，会直接截断对应的内容。通过畸形解析的差异，在特定的场景也可能达到参数走私的效果：