Apache Struts2远程代码执行漏洞修复

2017年那场席卷全球的远程Equifax数据泄露事件，让1.43亿美国人信息裸奔，代码罪魁祸首就是执行Struts2的S2-045漏洞。当时很多团队连夜打补丁的漏洞场景，我现在还记得——运维群里全是修复“重启了没”的刷屏。但更扎心的远程是，三个月后S2-048又爆了，代码那些只修了045的执行服务器再次中招。

Struts2的漏洞漏洞像韭菜，割了一茬又一茬。修复核心问题在于它把用户输入直接拼进OGNL表达式执行，远程攻击者用一串精心构造的代码HTTP头就能让服务器跑起任意命令。修复不是执行装个补丁就完事，你得理解它为什么反复发作。漏洞

最直接的修复修复手段是升级版本。别用老掉牙的2.3.x或2.5.x早期版，直接跳到官方最新稳定版。比如2.5.30之后，官方默认开启了`struts.ognl.allowStaticMethodAccess=false`，等于把OGNL的权限关进笼子。但升级前先看你的业务代码有没有依赖旧版OGNL特性，我见过有人升级后报表功能直接瘫痪，因为自定义拦截器里用了被禁用的静态方法。

如果暂时升不了级，至少得堵住入口。在web.xml里给Struts2的核心过滤器加个参数，把`struts.i18n.encoding`设为`UTF-8`，同时把`struts.multipart.maxSize`调小——很多攻击都藏在文件上传的Content-Type头里。更狠的做法是写个全局过滤器，拦掉所有带`%{ `或`${ `的请求参数。这法子简单粗暴，但小心误伤正常业务，比如搜索框里输入数学公式就会报错。

别忽略WAF的规则更新。ModSecurity有个专门针对Struts2的规则集，能拦截大部分已知攻击特征。但WAF不是万能钥匙，我记得某客户装了WAF照样被S2-057打穿，因为他们的规则库停在2018年，新漏洞的payload根本没收录。所以WAF规则要持续更新，最好配上威胁情报源。

运维层面有个容易被忽视的点：关闭Struts2的DevMode。开发环境开着调试模式方便，但生产环境开启等于把漏洞大门焊死。检查struts.xml里有没有``，有就立刻改成false。还有，把报错页面改成自定义的，别让堆栈信息直接裸露给用户——攻击者靠那些类名和方法名能精准定位漏洞点。

最后说个实战教训。某银行系统用Struts2做交易接口，他们按官方指南升级后，安全扫描还是报了高危。后来排查发现，是某个第三方jar包内嵌了旧版Struts2核心类，跟主应用版本冲突。用`dependency-check`这类工具扫一遍所有依赖，把不再用的老jar包从lib目录里清出去，不然你永远不知道哪个角落藏着定时炸弹。

修复Struts2漏洞不是一锤子买卖。它更像持续对抗——你堵住OGNL注入，攻击者就研究反序列化；你升级了组件，他们就找新的CVE。保持关注官方安全公告，每季度做一次漏洞扫描，比等出事再救火强得多。毕竟，你的服务器不是薛定谔的猫，漏洞在不在那儿，你心里得有数。