记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

FastJson checkAutoType安全机制研究

2020-08-19 13:04

在FastJson1.2.25以及之后的版本中,fastjson为了防止autoType这一机制带来的安全隐患,增加了一层名为checkAutoType的检测机制。

在之后的版本中,随着checkAutoType安全机制被不断绕过,fastjson也进行了一系列例如黑名单防逆向分析、扩展黑名单列表等加固。但是
checkAutoType的原理未曾有过大的变化,因此本文将以fastjson 1.2.25版本为例,介绍一下checkAutoType安全机制的原理

在调试分析fastjson的checkAutoType安全机制之前,发现网上很多fastjson漏洞的分析文章中曾经提到过一个名为autoTypeSupport的开关,且在1.2.25以及之后的版本中默认关闭。在动手调试之前,我曾一度以为autoTypeSupport开关关闭与否直接决定了fastjson是完全摒弃或是使用autotype功能的。但是实际调试中发现,这个开关仅仅是checkAutoType安全机制中的一个选项,这个开关的关闭与否,并不直接作用于fastjson是否使用autoType机制,下文案例中可以看出这个问题。

fastjson在1.2.25以及之后的版本中引入了一个checkAutoType安全机制,位于com/alibaba/fastjson/parser/ParserConfig.java文件。但并不是所有情况下fastjson都会加载这个机制进行安全监测,让我们下面来看看究竟什么情况下这个安全机制会被触发

通过调试fastjson 1.2.25代码发现,如果想触发checkAutoType安全机制,需要执行到com/alibaba/fastjson/parser/deserializer/JavaBeanDeserializer.java中下图红框处位置

首先看下在什么情况下不会使用checkAutoType安全机制

不使用checkAutoType安全机制的情况

一、json字符串中未使用@type字段

String jsonstr = "{\"s1\":\"1\"}";

显然,这里连@type字段都没有,这就是个最普通的json字符串转换为java对象的方法,因此根本进入不了上文中触发userType = config.checkAutoType(typeName, expectClass);的位置

二、Class\<T> clazz与@type相同

其次我们再看另一种情况

这里@type指定的类与parseObject(String text, Class\<T> clazz)中Class\<T> clazz)指定的类是一样的,都是AutoTypeTest.Test1

在上图中,由@type指定的typeName变量与parseObject(String text, Class\<T> clazz)中Class\<T>
clazz指定的beanInfo.typeName变量值完全一样,因此程序在这个if分支中,在这个上图红框中的if分支,程序不是break就是continue,无论如何也不会执行到上图552行的checkAutoType安全机制中

由上文两个例子可见,在1.2.25以及之后的版本中,并不是所有的情况都需要经过checkAutoType这一关卡的。

我们接下来看看如何触发checkAutoType安全机制,以及checkAutoType安全机制的原理

使用checkAutoType安全机制的情况

通过我的分析,checkAutoType安全机制中也是针对不同情况不同处理的,例如文章开头所说的autoTypeSupport开关等一些元素,这些元素总和起来一起觉得checkAutoType安全机制是如何过滤以及处理传入的等待反序列化的json字符串

总得来说,有如下几个元素共同作用影响checkAutoType选择哪种方式处理输入

1、autoTypeSupport开关值(True/False)

2、使用parseObject(String text, Class\<T> clazz)或是parseObject(String text)(这里Class\<T>
clazz参数为应与@type字段不一样的值,否则不会触发checkAutoType)

根据这两种条件,我们可以列出如下四种情况的表格

autoTypeSupport值parseObject(String text, Class\<T> clazz)/ parseObject(String text)
情况一FalseparseObject(String text)
情况二FalseparseObject(String text, Class\<T> clazz)
情况三TrueparseObject(String text)
情况四TrueparseObject(String text, Class\<T> clazz)

我们逐一分析

一、autoTypeSupport值为False、使用parseObject(String text)

由于autoTypeSupport为False,程序进入如下分支

程序首先遍历denyList这一黑名单,并判断className与黑名单是否匹配

这里需要说明一下className变量是从哪来的

className变量是由typeName简单变换而来的,详见下图代码

而typeName即为@type字段值

接下来看下黑名单中的元素

denyList =
"bsh,com.mchange,com.sun.,java.lang.Thread,java.net.Socket,java.rmi,javax.xml,org.apache.bcel,org.apache.commons.beanutils,org.apache.commons.collections.Transformer,org.apache.commons.collections.functors,org.apache.commons.collections4.comparators,org.apache.commons.fileupload,org.apache.myfaces.context.servlet,org.apache.tomcat,org.apache.wicket.util,org.codehaus.groovy.runtime,org.hibernate,org.jboss,org.mozilla.javascript,org.python.core,org.springframework"

如果className命中黑名单,程序抛出异常

autoType is not support.

程序结束

黑名单过滤完成后,程序还会将className与白名单匹配一下

这里的acceptList即为白名单,默认情况下为空

开发者可以自行向acceptList中增加元素。方法见下图48行处,向白名单中增加了一个AutoTypeTest.Test1类

当className与白名单相匹,程序会将这个类返回,并将传入的json字符串反序列化为这个类的对象

然而程序执行完黑名单与白名单校验后,即没有匹配到黑名单,也没有匹配到白名单的话,程序最终会执行到下图代码段

程序抛出异常结束

由于在1.2.25以及之后的版本中,autoTypeSupport值默认False。所以在这种情况下,即使攻击者的payload绕过了黑名单,但如果你的payload不在白名单上,也是不能成功利用的。值得注意的是,白名单默认是空的

在这种情况下,payload想执行成功,有一种可能性:

  1. @type字段值在不在黑名单中且在白名单中

二、autoTypeSupport值为False、使用parseObject(String text, Class\<T> clazz)

注意上图,这里parseObject中的Class\<T> clazz参数是AutoTypeTest.Test.class,而@type中的是AutoTypeTest.Test1,二者不是一个类。如果是一个类,根据上文checkAutoType触发条件分析,根本不会触发checkAutoType

程序会执行到如下if分支中

值得注意的是,这个分支中是先匹配白名单,后匹配黑名单,如果@type字段指定的类在白名单中,则直接返回,不需要再经过黑名单过滤了。这一点很有意思,如果开发者因为开发失误,将存在利用的类加到了白名单里,攻击者是可以直接利用的

回归正文,由于上图这里我们没有向白名单中增加AutoTypeTest.Test.class类,程序会接下来检查传入的类是否在黑名单中

如果匹配到黑名单,则直接抛出错误

如果这里既没有匹配到白名单直接返回,也没有匹配到黑名单抛出错误终止,程序则继续向下执行

继续执行到的这个分支与情况一中的完全一致,又匹配了一遍黑名单与白名单。显而易见,这里既不会匹配到白名单,也不会匹配到黑名单

最后程序执行到下图这里

由于我们使用的是parseObject(String text, Class\<T> clazz)
这种方式,上图代码中872行处的expectClass即为Class\<T>
clazz传入的AutoTypeTest.Test.class类,而clazz变量为@type字段指定的AutoTypeTest.Test1.class类.程序通过

expectClass.isAssignableFrom(clazz)

判断@type字段指定的clazz变量与Class\<T> clazz传入的expectClass是否

是判断 Class\<T> clazz传入的expectClass对象表示的类或接口是否与指定的@type字段指定的clazz变量参数表示的类或接口相同,或者是其超类或父接口。这里AutoTypeTest.Test.class类与AutoTypeTest.Test1.class类所表示的类与接口不同,也不是超类或父类关系。因此程序抛出

Exception in thread "main" com.alibaba.fastjson.JSONException: type not match.AutoTypeTest.Test1 -> AutoTypeTest.Test

异常

在1.2.25以及之后的版本中autoTypeSupport值默认为False。在这种情况下,程序会先匹配白名单,后匹配黑名单。如果@type字段指定的类在白名单中,则程序是会跳过黑名单校验的,例如下图

即使com.sun.rowset.JdbcRowSetImpl在黑名单中,但在开发的时候,由于开发安全意识不强或开发疏忽等原因,将com.sun.rowset.JdbcRowSetImpl加入了白名单,此时是可以绕过黑名单直接执行利用的

在这种情况下,payload想执行成功,有两种可能性:

1、没有命中黑名单且Class\<T> clazz表示的类或接口是否与指定的@type字段值表示的类或接口相同,或者是其超类或父接口。

2、@type字段值在白名单中

三、autoTypeSupport值为True、使用parseObject(String text)

这里首先进入了与autoTypeSupport值为False、使用parseObject(String text, Class\<T> clazz)类型相同的分支

先匹配白名单,后匹配黑名单。如果@type字段指定的类在白名单中,则直接返回,不再进行黑名单校验。在白名单未匹配成功后,使用黑名单进行匹配,若匹配到黑名单,直接抛出异常。如果黑白名单都未匹配成功,程序继续向下执行

程序将@type字段指定的类返回

这种情况下要是payload想成功利用有两种办法:

1、@type字段值只需要不在黑名单中即可成功利用

2、@type字段值在黑名单中,但是开发的时候在白名单中加入了这个类,payload依然可以成功利用

四、autoTypeSupport值为True、使用parseObject(String text, Class\<T> clazz)

与上文二、三节相同相同,先进入了这个分支

这里不再复述了

在没有匹配到黑白名单后,程序执行到了下图这里

由于这里clazz与expectClass所表示的类与接口不同,也不是超类或父类关系。因此程序抛出

Exception in thread "main" com.alibaba.fastjson.JSONException: type not match.AutoTypeTest.Test1 -> AutoTypeTest.Test

异常

在这种情况下,payload想执行成功,有两种可能性:

1、没有命中黑名单且Class\<T>
clazz表示的类或接口是否与指定的@type字段值表示的类或接口相同,或者是其超类或父接口。

2、@type字段值在白名单中

早期checkAutoType安全机制缺陷

在fastjson 1.2.25版本引入的checkAutoType以及后续的几个版本中存在着一定的缺陷

如上文所分析,程序通常先经过黑名单与白名单的校验后,将满足条件的clazz进行返回

我们来看下这个clazz是如何获得的

可见clazz是通过@type字段值获得而来

解析来看下TypeUtils.loadClass是如何实现的

注意上图的1089行

当传入的className变量以”L”开头,并以”;”结尾,进入上图分支

程序将会把开头的”L”与结尾的”;”去掉,并递归调用loadClass加载这个类

因此可以下图这样构造来进行绕过

loadClass会将”L”与”;”去除后组成newClassName并返回

这一操作在匹配黑白名单之后,Lcom.sun.rowset.JdbcRowSetImpl;恰好可以绕过黑名单中的限制。后续checkAutoType检测机制进行了一系列的安全加固,大体上都是黑名单防逆向分析、扩展黑名单列表等,但checkAutoType检测机制没有太大的改变。受篇幅影响,这里就不再详细分析了。


知识来源: xz.aliyun.com/t/8140

阅读:14935 | 评论:0 | 标签:安全

想收藏或者和大家分享这篇好文章→复制链接地址

“FastJson checkAutoType安全机制研究”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

ADS

标签云