struts1漏洞

2013年8月，漏洞一个安全研究员在Twitter上贴出一段代码，漏洞只有十几行。漏洞这段代码能直接打穿当时中国互联网上大半的漏洞政府网站和高校系统。漏洞名字叫Struts2，漏洞但真正被波及的漏洞，是漏洞它的前辈——Struts1。准确说，漏洞是漏洞Struts1在2008年就暴露出的一个反序列化问题，被后人翻出来反复利用，漏洞直到今天仍有零散攻击。漏洞 Apache Struts1是漏洞个老古董了。2000年发布，漏洞2013年EOL，漏洞官方停止维护。漏洞但中国大量老系统是拿它搭的骨架，银行、税务、医院挂号，甚至某些铁路售票系统的内网模块，都还跑着这身老骨头。没人敢动它，因为动一次就要重写整个业务逻辑，费用高到离谱，风险大到没人签字负责。 Struts1的核心问题在于它的ActionForm机制。开发者把用户提交的HTTP参数直接映射到JavaBean对象上，这个过程如果没做类型过滤，攻击者就能塞一串精心构造的字节流进去。服务器端反序列化时，这些字节流会变成一条命令执行链。打个比方，你往自动售货机投币口塞了张假钞，机器不仅吐了饮料，还按你写的指令把收银柜打开了。 我见过最典型的案例是某地级市公积金查询系统。攻击者只用了两个参数——一个指向恶意类的路径，一个触发命令的payload——就拿到了服务器权限。整个过程不到五秒，日志里只留下一条看似正常的POST请求。事后排查发现，这台服务器上的Struts1框架是2006年部署的，中间系统换过三次操作系统，Java版本从1.4升到1.8，但框架代码一行没动。 修复Struts1漏洞有个尴尬的地方——官方补丁只出到2012年，而且只修了已知的几个CVE。真正的隐患在于框架设计哲学本身：它信任用户输入，把类型转换和对象绑定混在一起。这不是打补丁能解决的，需要重构。但重构意味着推翻十多年的业务积累，很多甲方宁愿每年买安全设备、请渗透测试团队来“定期体检”，也不愿动底层代码。 更有意思的是，很多程序员在2013年后新写的项目里，居然还在用Struts1的变种思路——把JSON请求体直接绑定到POJO上，不做白名单校验。我见过一个2019年的新系统，用Spring MVC却模仿了Struts1的绑定方式，结果被一个老掉牙的OGNL注入打穿。这就像有人用最新款的保险箱，却把密码设成了123456。 Struts1的教训不是技术上的，而是工程管理上的。老系统不是不能换，是你得有个渐进式的迁移策略，而不是等漏洞被公开了才慌慌张张去临时打补丁。安全圈有句话：漏洞本身不可怕，可怕的是你不知道自己系统里跑着什么框架的哪个版本。很多公司连资产清单都做不完整，更别提跟踪框架的生命周期了。 到2024年，偶尔还能看到针对Struts1的攻击流量。那些老服务器像废弃的矿井，入口生锈了，但地下通道还连着主巷道。没人愿意花大价钱封死，于是每隔一阵就有人顺着旧图纸摸进去，翻出点数据或者挂个挖矿木马。这套路数，和十年前一模一样。