Struts2漏洞检查：别等黑客帮你测

2017年3月，漏洞某大型电商平台凌晨两点数据库被拖走，检查事后排查发现入口是漏洞Struts2的S2-045漏洞——一个存在了四年的老漏洞，官方补丁早就发了，检查但没人升级。漏洞这事不新鲜，检查每年都有企业栽在同一个坑里。漏洞Struts2的检查漏洞检查，说白了就是漏洞跟时间赛跑，你跑得慢，检查黑客就跑得快。漏洞

检查的检查第一步，不是漏洞扫漏洞，是检查搞清楚你用了哪个版本。很多人以为版本号写在pom.xml里就万事大吉，漏洞但实际运行环境里的jar包可能跟配置对不上。我见过一家公司，代码仓库显示是2.5.16，结果线上跑的是2.3.20——运维手动替换过旧包，没人记录。用`java -jar struts2-core-x.x.x.jar`这种方式直接看包名，或者解压后查MANIFEST.MF里的Implementation-Version，比信配置文件靠谱得多。

版本确认后，别急着上扫描器。手动验证几个关键点更实在。打开web.xml，看Struts2的过滤器映射——`struts2`的FilterDispatcher在2.3.15之前是默认配置，之后改成了StrutsPrepareAndExecuteFilter。如果还在用老类名，基本可以断定版本低于2.3.15，那S2-001到S2-016的远程代码执行漏洞大概率全中。这个判断不依赖任何工具，两分钟就能出结果。

接下来检查OGNL表达式的入口。Struts2的漏洞核心几乎都绕不开OGNL注入，而注入点往往藏在参数名里。手动提交一个`?redirect:%25{ 3*4}`，如果响应里出现12，说明OGNL执行没被拦截。更狠的测试是`?action:%25{ 233*233}`，返回54289就代表存在S2-016类型的风险。这种测试不会触发WAF告警，因为参数值本身不含恶意代码，但结果能直接暴露框架的解析逻辑。

别忽略异常日志。Struts2的报错页面有时会泄露classpath、文件路径甚至堆栈细节。访问一个不存在的action，看返回的404页面是否包含`org.apache.struts2.dispatcher`字样，如果有，说明devMode可能开着。devMode在2.5版本后默认关闭，但很多开发环境为了调试方便会手动开启，上线时忘了关——这是S2-048和S2-057能利用的前提条件之一。

真正靠谱的检查，得结合代码审计。搜一下项目里有没有`struts.xml`中配置了``，如果这个列表里没有`^dojo\..*`，那S2-007的注入点就还开着。再看`default.properties`里`struts.enable.DynamicMethodInvocation`是否为true，为true就允许`action!method`动态调用，S2-032就是靠这个打通的。这些细节扫描器未必能覆盖，但人工翻配置半小时就能查完。

最后说个反直觉的事：最新版本不等于安全。Struts2在2.5.20之前有个通病——`alwaysSelectFullNamespace`参数默认false，但某些情况下会被覆盖成true，导致S2-057。即便你升到2.5.22，如果业务代码里用了`ModelDriven`接口，OGNL的沙箱绕过依然可能发生。所以检查不能只盯框架版本，还得看自己的代码怎么用框架——安全是动态的，不是装个补丁就完事。

检查完把结果记录下来，日期、版本、测试参数、响应值，都写清楚。别只留一句“已检查无问题”，下次复查时你根本想不起当时测了什么。我在实际工作中吃过这个亏——三个月前手动测过S2-045没问题，但没记具体测试路径，后来系统升级后忘了重测，结果新版本反而引入了旧漏洞的回归。

Struts2的漏洞检查就是这样，没有银弹，没有一劳永逸的工具。你得花时间了解框架的运作方式，知道每个版本的改动点，然后用笨办法去验证。但正是这些笨办法，能救你于水火之中。