Struts2漏洞：一场持续了十年的漏洞噩梦

2010年7月，一个编号为S2-001的漏洞漏洞被公开。当时没人想到，漏洞这竟是漏洞Apache Struts2框架长达十年漏洞风暴的开端。这个Java Web框架，漏洞一度占据全球市场份额的漏洞60%以上，却因为一个又一个致命漏洞，漏洞成了黑客眼中的漏洞提款机。

S2-001的漏洞原理其实很简单——OGNL表达式注入。攻击者在表单参数里塞入恶意表达式，漏洞服务器就会乖乖执行。漏洞那时候很多开发者还不太当回事，漏洞毕竟"谁会通过URL传那么长的漏洞参数呢"。结果呢？漏洞没过多久，各种利用脚本就开始在暗网流传。漏洞

真正让Struts2"封神"的，是2017年的S2-045。这个漏洞利用的是Jakarta Multipart解析器的Content-Type头，不需要任何特殊权限，远程代码执行。Equifax（美国征信巨头）就是栽在这上面——1.43亿用户的社保号、信用卡信息被拖走。事后调查显示，他们明明有补丁，就是没打。

你可能会问，为什么一个框架能出这么多问题？根源在于Struts2的设计——它把OGNL表达式和HTTP参数混在一起解析。这就像把门钥匙和垃圾邮件放在同一个邮箱里，总有粗心的管理员会搞混。更糟的是，Struts2的补丁经常是"治标不治本"，修了S2-045，又冒出S2-046，本质都是同一个解析器的毛病。

我自己就遇到过"僵尸系统"。2018年给一家银行做安全审计，发现他们的网上银行后台还在用Struts2 2.3.20——这个版本至少存在8个已知RCE漏洞。运维主管苦着脸说："核心系统，不敢动，一动就出问题。"这种场景在国内尤其普遍，很多系统上线后就再没更新过依赖库。

Struts2的教训其实挺讽刺的：它输给了自己的"灵活"。OGNL表达式确实强大，但强大的另一面就是危险。现在的Spring Boot之所以更安全，恰恰是因为它默认把参数绑定和表达式解析严格分开。

到了2023年，Struts2的市场份额已经跌到不足5%。但别高兴得太早——那些老旧的金融、电信系统里，Struts2还顽强地活着。每次爆出新的CVE，安全圈都会掀起一阵"扫内网"运动。你看，S2-062、S2-066，一个接一个，就像打地鼠游戏。只要还有一台服务器跑着老版本，这个噩梦就不会结束。

下次你看到某个网站突然无法访问，或者某个APP的登录接口卡了十分钟，说不定就是有人在跟Struts2较劲呢。技术债这东西，迟早要还的——只是有些债，利息高得吓人。