fastjson漏洞(fastjson漏洞检测工具)
fastjson再曝重大安全漏洞，严重可导致服务瘫痪
2019年9月5日，fastjson在commit 995845170527221ca0293cf290e33a7d6cb52bf7上提交了旨在修复当字符串中包含\\x转义字符时可能引发OOM的问题的修复。
360CERT 判断该漏洞危害中。影响面较大。攻击者可以通过发送构造好的请求而致使当前线程瘫痪，当发送的恶意请求过多时有可能使业务直接瘫痪。
建议广大用户对自身的业务/产品进行组件自查，确认fastjson版本至少升级到1.2.60
漏洞的关键点在com.alibaba.fastjson.parser.JSONLexerBase#scanString中，当传入json字符串时，fastjson会按位获取json字符串，当识别到字符串为\\x为开头时，会默认获取后两位字符，并将后两位字符与\\x拼接将其变成完整的十六进制字符来处理：
而当json字符串是以\\x结尾时，由于fastjson并未对其进行校验，将导致其继续尝试获取后两位的字符。也就是说会直接获取到\\u001A也就是EOF：
当fastjson再次向后进行解析时，会不断重复获取EOF，并将其写到内存中，直到触发oom错误：
最终效果为：
fastjson 1.2.60版本
2019-09-03 fastjson提交修补commit
2019-09-05 360CERT发布预警
2019-09-07 周末加班升级！
PS：jackson最近也发布了多个版本进行漏洞修复。
Jackson替换fastjson的几个坑
最近fastjson漏洞频出，于是公司要求将所有的应用fastjson引用都换成jackson。这期间改造了大量应用，踩出来的坑珠峰倒进去估计也填不满。
首先是fastjson本身的一些小问题，由于其封装度很高，写起来比较偷懒。老应用中很多同事的偷懒写法，改的我几乎吐血。例如JSONArray，看似是对JSON对象的数组的封装，实际上什么都能放，就是一个ListObject，众所周知泛型写Object是最偷懒的写法，对后来者实在是太不友好了。。。遇到JSONArray的使用，改造时只能先写成ListObject，再小心翼翼的根据上下文，转换出具体类型。
说到类型转换，就不得不提JSONObject特别亲民的一系列getString()，getBigDecimal接口，写起来那叫一个方便。老应用中RESTFul接口的RequestBody也不定义Bean，直接JSONObject接着就完事，想用String就getString，当JSONObject被替换成Map的时候，再转String就不能直接用类型转换了，因为getString是兼容了其他不是String的类型的，当然也不能用String.valueOf方法，因为null类型的处理会有偏差。所以遇到这种情况，只能乖乖的自己写一个类型转换的工具类。每次看到这种 情况，我真的很想把开发的老哥揪回来问一句，你定义一个bean不香吗？
说到香，就不得不再说说我们新的真香--Jackson。fastjson在中文互联网之所以流行，顾名思义，它非常的fast。我做了一个简单的测试，分别使用fastjson和jackson，将一个Map转换成json字符串，测试结果如下
偶买噶，性能也相差无几。当然需要注意的是，自己封装jackson的工具类时，ObjectMapper最好写成单例，不然性能差不多会低上10倍吧。工具类的更换比业务逻辑的修改更容易踩坑。
说到坑，就不得不提Jackson的几个坑。在json字符串转换成bean时，jackson默认是大小写敏感的，也就是说，如果json中字段名是User，而bean的字段名是user，Jackson是不认识的，直接抛异常。解决起来倒是不复杂，ObjectMapper添加配置:
ObjectMapper mapper = new ObjectMapper();
mapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES,true);
此外，当json中的字段，bean中不存在时，jackson并不会忽略它，默认是抛出异常。稍微有点违反直觉。通过加配置也能解决：
ObjectMapper mapper = new ObjectMapper();
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
有没有什么Fastjson 漏洞的缓解策略？
JFrog DevOps 平台是不受Fastjson漏洞影响的。并且可以利用使用JFrog Xray来查找易受攻击的版本：除了暴露新的安全漏洞和威胁外，JFrog Xray SCA 工具通过自动安全扫描，让开发人员和安全团队轻松访问其软件的最新相关信息。JFrog Xray 执行 CVE 的自动上下文分析?加快解决实际可在生产中利用的漏洞的时间。JFrog 的上下文分析引擎可以检测非常量输入传递给易受此问题影响的 API 的 Java 二进制包（parse和parseObject），并验证 API 不会通过第二个参数将反序列化限制为特定类。
Fastjson 1.83漏洞利用猜想
在不久前fastjson1.2.83又爆出来了新的问题，详细内容可以参考 ，这篇文章主要是抛转引玉，写一种可能的利用思路，详细的利用链可能要等大佬们来给出了。
文内如有不妥之处，还请批评指正。
特定依赖存在下影响 ≤1.2.80
首先看白名单对比：
这里参考之前git上的白名单列表
像org.springframework中的基本全部从白名单中剔除了。
并且更改了判断方式，if (typeName.endsWith("Exception") || typeName.endsWith("Error"))
那么这里就可以猜测本次影响的方式，就是和被剔除的内容相关。这里用org.springframework.dao.CannotAcquireLockException进行测试，可以发现实际上最终调用的类是Throwable。
那么如果是要找gadget的话，就需要从黑名单下手了。本文不做分析和介绍，有兴趣找gadget的话可以去研究研究。
需要使用1.2.80和1.2.83的fastjson jar包进行测试。
maven
demo:
上重点从checkAutoType开始，简单的说一下判断过程。
首先是判断safeModeMask，通常默认是不会开的。
检测黑名单
通过黑白名单的检测，就会尝试从Mapping中获取类
走到这里如果是白名单里的内容会尝试进行加载。
并且会直接拿到对应的类，不会再进行接下来的校验。
由于存在继承调用关系，所以在进行加载的时候就会加载f1283，并且会重新进行checkAutoType的判定。
检测过程中会先将expectClassFlag置为true。
接着检测黑名单内容，Mapping获取以及白名单检测无果之后会对clazz的类型进行校验。
接着会进行新一轮的检测。
检测通过之后，会进行类继承关系判断，实际上只要继承关系正确，就会直接进行反序列化。
最后的结果
如果直接使用java.lang.Throwable会直接抛出异常。
我们来跟一下可以很清楚的看到，Throwable既不是黑名单，也不是白名单，也不是mapping中的内容。
那么在流程中就会将这个类当做一个普通的类来进行处理，通过判断autoTypeSupport为未开启的状态，从而进行抛出处理。