2013年7月，漏洞Struts2的漏洞S2-016漏洞被公开时，国内大量政府网站和银行系统瞬间变成了任人宰割的漏洞肉鸡。攻击者只需要构造一个以"redirect:"开头的漏洞URL参数，就能在服务器上执行任意命令。漏洞那会儿我刚入行不久，漏洞亲眼看着机房运维同事凌晨三点还在打补丁，漏洞嘴里骂骂咧咧——这破框架怎么又出事了。漏洞

Struts2是漏洞Apache基金会旗下的Java Web应用框架，早年靠MVC架构和标签库红极一时。漏洞它的漏洞核心是OGNL表达式，本来用来在JSP页面里方便地读写对象属性。漏洞问题恰恰出在这儿：OGNL太灵活了，漏洞灵活到能调用Java的漏洞Runtime类执行系统命令。框架开发者把用户输入直接塞进OGNL解析器，漏洞等于把枪口对准了自己的脚。

S2-016不是第一个，也远不是最后一个。从2010年的S2-005到2017年的S2-045，再到2020年的S2-059，Struts2的漏洞名单长得像一卷卫生纸。每次补丁发布后，总有开发团队因为项目太老、依赖太深、没人敢动而选择忽略。我见过一个省级单位的内部系统，Tomcat日志里全是"Content-Type: %{ ...}"的探测记录，管理员却摆摆手说“内网没事”。结果呢？攻击者从一台打印机跳板进来，三天后数据库被拖了个干净。

漏洞利用的门槛低得离谱。S2-045只需要在HTTP请求的Content-Type头里写一段OGNL表达式，比如%{ #context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Test','test')}，如果响应头里出现X-Test，就说明漏洞存在。再换成执行命令的payload，服务器就沦陷了。整个过程不需要任何认证，一个curl命令搞定。

为什么Struts2总在同一个坑里摔跤？我的观察是，框架设计者过度追求“开发者友好”，把便利性凌驾于安全性之上。OGNL表达式可以访问上下文中的任意对象，包括Servlet API和系统属性。每次修补都是黑名单过滤，攻击者换个编码方式或利用链就能绕过。这种打地鼠式的防御，注定疲于奔命。

更让人头疼的是企业环境里的遗留系统。很多银行、电信的后台跑着Struts 2.3.x，代码里嵌着大量自定义拦截器和第三方插件。升级到2.5.x意味着重写部分业务逻辑，测试周期动辄数月。于是运维人员选择在WAF上加规则，结果攻击者用分块传输编码或者畸形的multipart请求就能绕过。我见过最离谱的案例，某单位把Struts2的jar包版本号改成了2.5.30，实际代码还是2.3.15——掩耳盗铃到这种地步。

如果你现在还在维护Struts2项目，别抱侥幸心理。先跑一遍mvn dependency:tree | grep struts2，看看版本号。低于2.5.30的，尽快升级。实在升不动，至少把struts.enable.DynamicMethodInvocation设为false，禁用动态方法调用。然后检查所有Action的输入参数，别让用户数据直接进OGNL。WAF只能挡脚本小子，挡不住真正盯着你系统的对手。

说到底，Struts2的漏洞史就是一部Java Web安全的反面教材。它提醒我们：框架的便利性和攻击面往往成正比。当你用一行标签搞定数据绑定时，可能也在某个角落埋下了一颗定时炸弹。安全这件事，偷懒的代价迟早要还。