内容摘要：fastjson漏洞检测工具：一场与反序列化炸弹的赛跑 凌晨两点，某电商平台的告警群里炸了锅——一台应用服务器CPU飙到100%，日志里全是`com.alibaba.fastjson.JSONExce

fastjson漏洞检测工具：一场与反序列化炸弹的漏洞赛跑

凌晨两点，某电商平台的检测告警群里炸了锅——一台应用服务器CPU飙到100%，日志里全是工具`com.alibaba.fastjson.JSONException`。运维小哥手动重启三次，漏洞每次撑不过十分钟又被打爆。检测后来排查发现，工具攻击者只发了一个HTTP请求，漏洞就通过fastjson的检测autoType机制远程执行了命令。这类场景，工具过去三年我在不同客户现场见了不下十次。漏洞

fastjson的检测漏洞本质不复杂：它允许JSON字符串里嵌套类名，反序列化时如果没关掉autoType，工具攻击者就能构造恶意类触发任意代码执行。漏洞但麻烦在于，检测漏洞变种像韭菜，工具CVE-2017-18349刚堵上，又冒出CVE-2019-12814，接着是1.2.68版本的绕过链，再到2022年的“浅蓝”利用。光靠升级版本根本追不上，因为业务代码里可能埋着几百个`JSON.parseObject()`调用，你根本不知道哪个接口会传进来什么鬼东西。

所以检测工具就成了刚需。市面上的工具分两类：一类是黑盒扫描，直接往目标接口塞payload看反应；另一类是白盒审计，扫代码里的fastjson调用点，比对版本和配置。我见过最蠢的黑盒工具，把所有已知payload挨个打一遍，结果把客户的生产环境打崩了——它没判断对方是否开了autoType，盲目触发了解析流程。真正靠谱的黑盒工具得先探测指纹，比如发一个`{ "@type":"java.lang.Class"}`看返回差异，确认目标用的是fastjson还是Jackson，再针对性测试。

白盒工具又是另一套逻辑。Fastjson的漏洞触发需要三个条件：autoType开启、存在可利用的gadget类、反序列化点有用户可控输入。白盒工具要干的事就是静态扫描这三条链。有个开源工具叫`fastjson-exp`，做得挺聪明，它用AST语法树解析字节码，能识别出哪些类继承了`AbstractTranslet`或者实现了`TemplatesImpl`接口——这些就是潜在gadget。但静态扫描有个死穴：误报率感人。你扫出来一百个风险点，可能九十九个都是因为业务代码里确实用了`ParserConfig.getGlobalInstance().setAutoTypeSupport(true)`，但实际输入根本到达不了那个解析函数。

我自己用下来，最顺手的是把两个工具串起来：先用白盒工具定位所有反序列化入口，手工看一遍代码确认哪些入口暴露在公网；再用黑盒工具对这些入口做精准payload测试。有个案例印象很深——某金融客户的核心交易系统，白盒扫出37个风险点，黑盒打了半天一个都没触发。后来人工review发现，他们的fastjson版本是1.2.83，但业务代码里自定义了一个`ObjectDeserializer`，恰好绕过了默认的安全开关。这种逻辑漏洞，工具永远发现不了，只能靠人肉。

别指望工具能一劳永逸。fastjson的维护者其实一直在修，但攻击者总能在代码审计里找到新思路。比如1.2.83版本虽然默认关闭autoType，但如果你在配置里显式添加了某些白名单类，攻击者照样能利用。检测工具的价值在于帮你缩小排查范围，而不是替代安全审查。我见过最惨的团队，用了某商业扫描器，报告显示“零风险”，结果上线第二天就被打穿——因为他们的fastjson是通过SPI机制动态加载的，扫描器根本没扫到那个自定义ClassLoader。

说到底，工具是死的，人是活的。你真正该做的，是把fastjson换成Gson或者Jackson（如果业务允许），或者至少在fastjson前面加一层WAF规则，拦截`@type`关键字。实在换不了，那就勤快点儿，每次官方发安全公告，第一时间去diff源码，看改动点，自己写针对性的检测脚本。这活儿不轻松，但比半夜爬起来扛攻击强。