2017年9月，中间Apache官方发布了一个Tomcat安全公告，程代编号CVE-2017-12615。码执那个时间点，行漏国内大量中小企业的中间OA系统、门户网站还在用Tomcat 7跑着JSP页面。程代攻击者只需往服务器上传一个特殊命名的码执JSP文件，就能直接拿到服务器权限。行漏这不是中间理论推演，是程代当时真实发生的批量入侵事件。

漏洞的码执根子出在Tomcat的DefaultServlet配置上。Tomcat默认的行漏web.xml里，readonly参数被设为false，中间意味着允许通过HTTP PUT方法向服务器写入文件。程代更致命的码执是，Windows环境下文件名末尾的点号会被系统自动忽略——攻击者上传shell.jsp.，Tomcat检查时看到的是.jsp.后缀，判定为非法，但Windows落盘时把末尾的点吃掉了，实际生成的是shell.jsp。绕过了后缀校验，一个WebShell就这么种进去了。

这套利用链的巧妙之处在于它不需要任何0day。PUT方法本身就是HTTP协议的一部分，Tomcat只是错误地开放了它。很多运维人员甚至不知道自己的Tomcat支持PUT——他们装完中间件、丢个war包进去就完事了，从来没检查过conf/web.xml里那行配置。

我见过一个案例。某地级市的人才招聘网站，服务器上跑着Tomcat 7.0.79。攻击者用PUT上传了一个cmd.jsp.，内容就几行代码，接收request.getParameter("cmd")然后Runtime.exec()执行。从上传到执行命令，整个过程不到三秒。网站首页后来被挂上了博彩广告，运维团队两天后才发觉。日志里PUT /cmd.jsp.的请求记录明明白白躺在那里，但没人看。

修复方案其实简单得不像话。把conf/web.xml中DefaultServlet的readonly参数改成true，重启Tomcat，漏洞就堵上了。或者直接升级到Tomcat 7.0.81+、8.5.20+、9.0.0.M22+，官方在这些版本里默认禁止了PUT写文件。但现实是，很多服务器从部署那天起就没打过补丁。运维交接时只丢一句“Tomcat跑在8080端口”，配置文件长什么样没人关心。

这个漏洞暴露的问题比漏洞本身更值得琢磨。Tomcat作为Servlet容器，默认配置偏向功能可用性而非安全加固。readonly=false这种设定，在开发环境里方便调试，到了生产环境就是敞开的大门。中间件安全经常被忽略——大家盯着业务代码的SQL注入、XSS，却忘了承载业务的容器本身可能就是个入口。

另一个细节：CVE-2017-12615只影响Windows。Linux下文件名末尾的点不会被忽略，上传shell.jsp.得到的还是shell.jsp.，Tomcat能正确拦截。但很多企业内网混用Windows Server和Linux，攻击者不会挑系统，他们批量扫描，哪个能打就打哪个。

如果你现在手里还有Tomcat 7的服务器，第一件事就是去翻conf/web.xml。搜readonly，看它是true还是false。false的话，别犹豫，改掉，重启。别等扫描器找上门再动手。安全这件事，事后补救的成本永远比事前配置高出一个数量级。