Struts2漏洞原理：一场关于"标签"的漏洞暗战

2017年，某电商平台被拖库，原理几百万条用户信息在暗网明码标价。漏洞事后溯源，原理攻击者用的漏洞不是0day，而是原理Struts2早已公开的S2-045漏洞。修复补丁打了三个月，漏洞可惜运维漏了一台服务器——就那一台，原理成了整个系统的漏洞缺口。

Struts2的原理漏洞，核心不在Java代码，漏洞而在它那套引以为傲的原理OGNL表达式引擎。这玩意儿本来是漏洞用来在视图层和模型层之间传递数据的，比如用户提交表单，原理Struts2就通过OGNL把参数塞进Java对象里。漏洞问题是，OGNL太强大了，它能调用静态方法、访问任意类属性，甚至执行系统命令。一个本该只处理"字符串"的地方，突然能跑任意代码——这就像你把车钥匙交给代客泊车，结果那人能开你的车去抢银行。

攻击手法说起来很直白。Struts2接收HTTP请求时，会解析Content-Type、Content-Disposition这类头信息。某些版本里，这些头的值直接拼进了OGNL表达式。攻击者只要在头里塞一段精心构造的OGNL代码，比如#cmd='id'，再配合new java.lang.ProcessBuilder()来执行，服务器就乖乖交出了权限。整个过程不用登录，不用上传文件，一个curl命令就搞定。

最讽刺的是，很多漏洞的触发点其实是为了"修复"之前的问题。比如S2-032，官方为了限制OGNL调用静态方法，加了个安全模式。可安全模式本身又存在绕过——通过递归调用、动态方法调用，或者利用异常处理里的表达式二次解析，就能把锁撬开。这就像你给门上了三道锁，结果小偷发现窗户没关。

我自己做过一次测试。本地搭了个老版本Struts2，发了个带恶意Content-Type的请求，服务器直接执行了whoami，返回"root"。那一刻我后背发凉——这不是什么高深技巧，而是任何人都能在网上搜到的现成payload。企业里那些跑了几年的老系统，如果没人盯着版本更新，基本就是裸奔状态。

漏洞的根源，是设计理念和现实需求的错位。OGNL追求"表达一切"，但Web输入本质上是不可信的。Struts2的开发者显然低估了攻击者的想象力——他们没想到会有人把HTTP头当代码来喂。后来官方也学乖了，默认禁用OGNL静态方法调用，把执行权限关进笼子里。但每次修补，都像打地鼠：S2-045堵上了，S2-046又冒出来，换了个参数位置，原理一模一样。

这类漏洞真正可怕的地方在于"连锁反应"。攻击者拿到Webshell后，会立刻提权、横向移动。我见过一个案例，黑客通过Struts2漏洞进了一台前台服务器，然后利用内网弱口令，一路摸到数据库主库。整个过程不到半小时。事后排查时发现，日志里那个攻击IP在三个月前就扫描过系统——人家早就在等了，就等你漏出破绽。

所以别指望"升级到最新版"就万事大吉。Struts2的历史漏洞列表有几十页，每个版本都带着几个未修复的坑。真正稳妥的做法是：把Struts2换成Spring MVC这类更克制的框架，或者至少用WAF拦截OGNL特征。但很多老项目动不了，那就得把服务器隔离、权限最小化、日志全量记录。安全没有银弹，只有不断缩小攻击面。

说到底，Struts2漏洞是一场关于信任的教训——你给了框架太多能力，却没想过它可能被反噬。代码里每一个"方便"的接口，都可能成为攻击者的梯子。

很赞哦!（72165）