fastjson到底做错了什么?为什么会被频繁爆出漏洞?(推荐)

因为fastjson默认关闭了autotype支持，并且做了黑白名单的校验，所以攻击方向就转变成了"如何绕过checkAutotype"。

下面就来细数一下各个版本的fastjson中存在的漏洞以及攻击原理，由于篇幅限制，这里并不会讲解的特别细节，如果大家感兴趣我后面可以单独写一篇文章讲讲细节。下面的内容主要是提供一些思路，目的是说明写代码的时候注意安全性的重要性。

绕过checkAutotype，黑客与fastjson的博弈

在fastjson v1.2.41 之前，在checkAutotype的代码中，会先进行黑白名单的过滤，如果要反序列化的类不在黑白名单中，那么才会对目标类进行反序列化。

但是在加载的过程中，fastjson有一段特殊的处理，那就是在具体加载类的时候会去掉className前后的L和;，形如Lcom.lang.Thread;。

而黑白名单又是通过startWith检测的，那么黑客只要在自己想要使用的攻击类库前后加上L和;就可以绕过黑白名单的检查了，也不耽误被fastjson正常加载。

如Lcom.sun.rowset.JdbcRowSetImpl;，会先通过白名单校验，然后fastjson在加载类的时候会去掉前后的L和，变成了com.sun.rowset.JdbcRowSetImpl`。

为了避免被攻击，在之后的 v1.2.42版本中，在进行黑白名单检测的时候，fastjson先判断目标类的类名的前后是不是L和;，如果是的话，就截取掉前后的L和;再进行黑白名单的校验。

看似解决了问题，但是黑客发现了这个规则之后，就在攻击时在目标类前后双写LL和;;，这样再被截取之后还是可以绕过检测。如LLcom.sun.rowset.JdbcRowSetImpl;;

魔高一尺，道高一丈。在 v1.2.43中，fastjson这次在黑白名单判断之前，增加了一个是否以LL未开头的判断，如果目标类以LL开头，那么就直接抛异常，于是就又短暂的修复了这个漏洞。

黑客在L和;这里走不通了，于是想办法从其他地方下手，因为fastjson在加载类的时候，不只对L和;这样的类进行特殊处理，还对[也被特殊处理了。

同样的攻击手段，在目标类前面添加[，v1.2.43以前的所有版本又沦陷了。

于是，在 v1.2.44版本中，fastjson的作者做了更加严格的要求，只要目标类以[开头或者以;结尾，都直接抛异常。也就解决了 v1.2.43及历史版本中发现的bug。

在之后的几个版本中，黑客的主要的攻击方式就是绕过黑名单了，而fastjson也在不断的完善自己的黑名单。

 4/7   首页 上一页 2 3 4 5 6 7 下一页 尾页