tomcat漏洞扫描工具，漏洞别只盯着版本号

我上周帮朋友排查一个老项目的扫描部署问题，顺手用扫描工具扫了一圈他的工具Tomcat 8.5.51。结果报告弹出一堆“中危”“低危”，漏洞但真正让我后背发凉的扫描，是工具其中一个被称为“幽灵猫”的路径穿越漏洞——它压根不看你版本号，只要默认配置没改，漏洞谁都能读你服务器上的扫描`/etc/passwd`。这让我想起很多团队的工具做法：升级到最新版Tomcat，然后安心睡觉。漏洞可现实是扫描，漏洞扫描工具的工具价值，恰恰在于揪出那些你“以为没事”的漏洞角落。

先说说工具本身。扫描市面上的工具选择不算少，但分两类：一类是像Nessus、OpenVAS这种综合扫描器，它们把Tomcat当普通Web服务，测的是常见CVE和错误配置；另一类是专门针对Tomcat的脚本集合，比如`tomcatscan`（GitHub上那个Python写的）或者Burp Suite里挂的扩展。前者适合定期巡检，后者适合渗透测试时快速摸底。我个人偏好后者——因为Tomcat的坑，往往不在HTTP协议层，而在它的管理后台、AJP连接器、以及那些不起眼的JSP预编译功能上。

举个例子，很多人不知道Tomcat 9.0.31之前有个AJP文件读取漏洞（CVE-2020-1938），攻击者只要发送一个特殊构造的AJP请求，就能绕过前端Nginx直接读WEB-INF目录下的配置文件。这漏洞不需要任何认证，甚至能配合其他漏洞执行命令。可你拿Nessus扫，它多半只报“AJP端口开放”，压根不提示风险等级——因为它默认AJP是内网协议，觉得暴露在外网是小概率事件。但现实里，多少运维图省事，把8009端口直接映射到公网？我见过不止一次。

所以我的建议是：工具要分层用。第一层，用OpenVAS做全端口基础扫描，看有没有暴露的8005、8009、8080端口，顺便查下系统补丁情况。第二层，用`tomcatscan`这类专门工具，重点测管理路径（比如`/manager/html`）是否弱口令、`/host-manager`是否可未授权访问、以及那些已知的路径穿越和反序列化漏洞。第三层，手动验证——工具报“可能存在漏洞”时，别急着写报告，自己curl一下URL，看响应头里有没有`Apache-Coyote/1.1`，或者试着访问`/..;/`这种奇葩路径。

有一个细节我特别想提：扫描工具对Tomcat的“默认文件”特别敏感。比如`/examples`目录，很多版本自带示例应用，里面藏了WebSocket和JSP的调试接口，这些接口在旧版本里能直接执行代码。工具会报“信息泄露”，但实际利用难度很低。我上次扫一个测试环境，发现`/examples/servlets/servlet/SessionExample`还在跑，顺手用默认的`tomcat`用户试了下弱口令，结果直接登进后台部署了war包——整个过程五分钟。这不是工具厉害，是Tomcat的默认配置太“信任”管理员了。

最后说点主观判断。别迷信“最新版就安全”。Tomcat 10.1.x虽然修复了老漏洞，但引入了Jakarta命名空间，很多老应用直接跑不起来，运维被迫降级到9.0.x——而9.0.x的某些小版本（比如9.0.30到9.0.40之间）存在已知的并发处理缺陷，扫描工具未必能测出来。真正靠谱的做法是：每次扫描后，把报告里的CVE编号和Tomcat官方安全页（tomcat.apache.org/security.html）逐一比对，看修复版本和实际版本的差距，然后决定是升级还是打补丁。工具只是给你指了个方向，最后拍板的还是人。