Apache Tomcat的任意任意文件上传漏洞（CVE-2017-12615）是个老掉牙的坑，但直到今天，文件网上扫描器随便一挂，上传还能扫出一堆裸奔的漏洞服务器。这个漏洞的任意利用条件苛刻得近乎可笑——它只影响Windows系统上的Tomcat 7.0.x版本，且readonly参数必须被设为false。文件默认配置下Tomcat是上传安全的，但总有管理员为了图省事，漏洞改掉那个参数，任意然后把自己送进漏洞名单。文件

漏洞的上传核心在于Tomcat对HTTP PUT请求的处理逻辑。当readonly=false时，漏洞攻击者可以直接向服务器发送PUT请求上传文件。任意但Tomcat的文件servlet容器有个诡异的过滤规则——它禁止上传.jsp文件。于是上传攻击者开始耍小聪明，用filename.jsp%20、filename.jsp::$DATA或者filename.jsp/这类变体绕过检查。Windows文件系统会忽略末尾的空格、::$DATA是NTFS的备用数据流标识，而末尾的斜杠则能触发Tomcat的路径规范化逻辑。最终，一个名为shell.jsp的恶意文件就这样被写进了webapps目录。

我见过一个真实的案例。某政府网站的子域名被人用这个洞塞进了一个冰蝎马，攻击者还贴心地清理了访问日志。管理员发现时，服务器已经被用来发起DDoS流量长达两周。最讽刺的是，这台机器上跑着最新版的JDK，防火墙策略也做得滴水不漏，唯独Tomcat的配置文件里，readonly那个参数被人改成了false——大概是某个外包工程师为了测试方便留下的。

修复方案其实很粗暴：把readonly改回true，或者升级到Tomcat 7.0.79以上版本。但真正值得思考的是，为什么一个2017年就公开的漏洞，至今仍在被批量利用？我翻过一些暴露在公网的Tomcat服务器，相当一部分是老旧项目，没人愿意为“不产生直接收益”的维护工作买单。还有些是内网机器被映射到了公网，运维压根不知道有这台设备存在。

这个漏洞的另一个有趣之处在于它只对Windows生效。Linux下的Tomcat即使配置错误，也不会因为空格或::$DATA绕过检查。这算是个冷知识——很多扫描器在Linux上测试这个漏洞时会误报，因为它们只检查了PUT请求是否被接受，而没有验证文件是否真的写入了磁盘。

如果你还在维护老旧的Tomcat，建议立刻检查conf/web.xml里的readonly参数。别以为内网就安全——勒索软件和内网穿透工具早已把爪子伸向这些角落。安全这事，懒不得。

(责任编辑：休闲)