这篇东西不整虚的，直接告诉你怎么在 S2 烂摊子上续命，或者什么时候该彻底放弃。如果你正头疼那个该死的 CVE-2017-5638 或者更老的 RCE 漏洞，看完这篇能帮你省下几十万的安全整改费。
上周三凌晨两点，我盯着监控大屏，心率飙到 120。客户那个用了 S2 做了三年的后台系统，突然被挂马了。不是那种小打小闹的弹窗，是直接在首页加了博彩链接。运维大哥手抖着给我打电话，声音都在飘：“哥，完了，数据好像被扫了。” 我骂了一句脏话，抓起键盘就开始排查。这场景太真实了，真实到让人想吐。很多老板觉得，只要不对外网开放端口就万事大吉，简直是天真的可爱。内网横向移动，或者通过上传点打进来，比你想的容易得多。
咱们得承认，Struts2 是个好框架，至少在十年前它是。但时代变了，它老了，老得像你爷爷那辈的收音机，零件难找，还容易漏电。用 struts2 做的网站 现在就像是个定时炸弹，虽然不一定马上炸，但你知道它在那儿。我见过太多项目，因为历史包袱重，不敢动，结果一旦出事就是毁灭性的。
先说最头疼的上传漏洞。很多老系统，文件上传逻辑写得那叫一个随意。直接判断后缀名？别逗了。黑客随便改个 HTTP 头，或者利用图片马，就能把 JSP 上传上去。一旦上传成功，那就是后门大开。我有个客户，为了省事，把上传目录直接放在了 Web 根目录下，还给了执行权限。结果呢？黑客上传了一个叫 image.jpg.jsp 的文件，直接拿到服务器权限。这种低级错误，在那些用 struts2 做的网站 里简直不要太常见。
再说那个著名的 OGNL 注入。S2 的参数解析机制，简直是黑客的乐园。以前我们总想着打补丁，加过滤器，搞白名单。但你会发现，S2 的拦截器链太复杂，你补了一个洞，它又露出一个新嘴。就像打地鼠，你按下去一个，另一个又弹起来。这种维护成本，高到让人绝望。
我有个朋友，公司核心业务系统就是 S2 架构。老板为了省钱，不让重构，只让打补丁。结果去年被勒索软件盯上了。加密了所有数据库文件，勒索 50 万比特币。最后没办法，只能花 80 万请了顶级安全团队，加上从冷备里恢复数据，折腾了半个月。那半个月，整个团队没睡过一个整觉。这笔账，怎么算都是重构划算。
所以，我的建议很直接。如果你们公司还在用 struts2 做的网站 做核心业务，听我一句劝，赶紧规划迁移。别指望什么“安全加固”能一劳永逸。你可以做几件事：第一，把所有上传功能独立出来，放到专门的静态资源服务器，比如 OSS 或 CDN，绝对不要放在应用服务器本地。第二，关闭不必要的调试参数，struts.devMode 必须设为 false。第三，升级 S2 到最新的安全版本，虽然这没啥大用，但聊胜于无。
当然，如果预算允许，尽快上 Spring Boot 或者 Spring Cloud。现在的生态，S2 真的跟不上节奏了。社区没人维护了，新的漏洞没人报，或者报了也没人修。这种孤独感，只有用过的人才懂。
最后，别信那些说“S2 很安全”的鬼话。安全是动态的，没有绝对的安全。只有不断的迭代和升级。如果你现在正面临 S2 的安全困境，不知道从何下手，或者想评估迁移成本，可以来找我聊聊。我不卖课，只谈技术，只讲实话。毕竟，看着别人的系统被黑，比自己被黑还难受。
