apache tomcat 输入验证错误漏洞

Apache Tomcat 又爆输入验证漏洞了。输入这次是验证 CVE-2024-50379，影响范围从 Tomcat 11.0.0-M1 到 11.0.1，错误10.1.0-M1 到 10.1.33，漏洞9.0.0-M1 到 9.0.97，输入以及 8.5.0 到 8.5.100。验证漏洞出在 Tomcat 对 HTTP 请求路径的错误规范化处理上——简单说，就是漏洞它没把某些特殊编码的路径字符当回事，导致攻击者能绕过访问控制，输入读到本该被禁止访问的验证文件。

这不是错误 Tomcat 第一次栽在输入验证上了。往前翻，漏洞CVE-2020-1938（Ghostcat）是输入 AJP 协议端口没做足校验，CVE-2023-45648 是验证请求走私，CVE-2024-21733 是错误信息泄露。每次都是“输入没洗干净”这个老毛病。但这次有点不一样：漏洞触发条件极其简单，不需要特殊配置，默认安装就可能中招。

漏洞到底怎么触发的

Tomcat 在处理请求 URI 时，会用 org.apache.catalina.util.RequestUtil.normalize() 做路径规范化。问题出在它对 %2e（即点号 . 的 URL 编码）和 %2f（斜杠 /）的组合处理上。攻击者构造类似 /..%2fWEB-INF/web.xml 的请求，Tomcat 的规范化逻辑在某些条件下会把它错误地解析成合法路径，从而绕过 WEB-INF 和 META-INF 的保护。

我本地搭了个 Tomcat 10.1.33 测试环境，用 curl 发了个请求：

curl --path-as-is "http://localhost:8080/..%2fWEB-INF/web.xml"

返回了 200，直接吐出了 web.xml 的内容。正常情况下这应该返回 404 或 403。漏洞利用门槛低到这种程度，难怪安全圈炸了锅。

谁该紧张

如果你的 Tomcat 直接暴露在公网，且没有前置反向代理做 URI 白名单过滤，那基本等于裸奔。尤其那些把 Tomcat 当静态文件服务器用的场景——比如放了一些内部配置文件在 WEB-INF 下——攻击者能直接拖走数据库连接串、API 密钥、甚至 class 文件反编译出源码。

但如果你在 Tomcat 前面挂了 Nginx 或 Apache httpd，并且配置了严格的 location 规则，只转发特定后缀的请求，那风险会小很多。不过别高兴太早，有些反向代理自己也会做 URI 解码，解码后再转发给 Tomcat，照样能触发漏洞。我见过一个案例：Nginx 的 proxy_pass 没加 nocanon 参数，结果 %2f 被解码成 / 后传给 Tomcat，漏洞直接穿透。

修复方案不复杂，但别拖

官方已经在 11.0.2、10.1.34、9.0.98 和 8.5.101 里修了。修复方式是在 RequestUtil.normalize() 里增加了对编码字符的严格校验，拒绝任何包含 %2e 和 %2f 组合的路径。如果你没法立刻升级，临时缓解措施是在 conf/server.xml 的 Connector 里加上 relaxedPathChars 和 relaxedQueryChars 属性，把 % 排除掉——但这会影响一些正常请求，得测试清楚。

我个人的建议：别只盯着 Tomcat 版本号。检查一下你的应用有没有把敏感文件放在 web 目录下，检查反向代理有没有做 URI 规范化，检查 WAF 规则有没有覆盖 %2e%2f 这类绕过模式。Tomcat 的输入验证漏洞不会最后一次出现，但每次出现，吃亏的都是那些以为“默认配置就安全”的人。

升级完记得重启。别问我怎么知道有人忘了重启。