jackson databind反序列化漏洞
2017年那个夏天，序列安全圈被一个CVE编号刷了屏——CVE-2017-7525。化漏jackson-databind的序列enableDefaultTyping()方法成了众矢之的。攻击者只需要构造一段恶意JSON，化漏就能让服务器执行任意代码。序列我当时在测试环境复现，化漏看着一个简单的序列{ "@class":"com.sun.rowset.JdbcRowSetImpl"}直接弹出了计算器，后背发凉。化漏这不是序列什么花哨的0day，而是化漏用了两年多的老洞。
问题出在哪儿？序列enableDefaultTyping()允许JSON中携带类型信息，反序列化时就直接按这个类名去实例化。化漏设计初衷是序列为了多态支持——你有个Animal接口，想反序列化成Dog还是化漏Cat，全靠JSON里的序列@class字段说了算。但攻击者根本不关心你的业务类，他们瞄上的是JDK自带的一些“危险”类。比如JdbcRowSetImpl，它有个特性：设置dataSourceName后，调用getConnection()就会发起JNDI查询。配合一个恶意的LDAP/RMI服务，就能加载远程class，直接RCE。
这个漏洞最阴险的地方在于——不需要你代码里有任何反序列化逻辑。只要你的项目用了jackson-databind，并且开了默认类型，哪怕只是解析一个用户提交的JSON，都可能中招。很多开发者根本不知道这个开关的存在，更不知道它默认是关闭的。但总有那么些框架，比如Spring Boot的某些版本，或者一些老旧的配置，悄悄把它打开了。等到出事儿的时候，日志里只有一行Invalid type definition，你甚至不知道攻击已经发生。
官方修复方式也很有意思——不是移除这个功能，而是维护了一个黑名单。把JdbcRowSetImpl、XString、TemplatesImpl这些已知的“危险类”全部禁掉。但黑名单就像打地鼠，安全研究员们不断发现新的gadget，官方就得不停打补丁。2019年又爆出绕过黑名单的CVE-2019-12384，利用的是com.zaxxer.hikari.HikariConfig。所以后来jackson干脆在2.10版本里把默认类型机制彻底改了——不再支持任意类，必须显式指定白名单。
说实话，这个漏洞给我最大的教训是：反序列化库的“便利性”往往就是“攻击面”。你图它省事，它就能让你翻车。现在写代码，我基本不用enableDefaultTyping()，就算用也必开白名单。而且强烈建议升级到2.10+，把黑名单那套老古董扔进历史的垃圾堆。毕竟，安全这种东西，靠维护黑名单永远是被动的——攻击者总有你没想到的姿势。
最后提醒一句，如果你的项目还在用旧版jackson，赶紧去查一下有没有开默认类型。别等安全扫描工具报出高危漏洞才慌，那时候可能已经晚了。