Tomcat的示例示例脚本里藏着一条老掉牙的信息泄露漏洞，至今仍在不少生产服务器上裸奔。脚本这不是信息泄露什么高深莫测的零日漏洞，而是漏洞Apache Tomcat默认安装包中examples目录下几个JSP文件未做访问限制导致的。攻击者只要知道路径，示例就能直接通过浏览器读到服务器上的脚本敏感文件。

具体来说，信息泄露问题出在/examples/jsp/目录里的漏洞session.jsp和foo.jsp这类示例文件。它们内部调用了request.getRequestDispatcher()，示例但没对传入的脚本路径参数做任何过滤。你可以在URL里塞上?信息泄露jsp=../conf/tomcat-users.xml，服务端就会傻乎乎地把配置文件内容回显出来。漏洞更狠的示例是，如果配合..%2f这种编码绕过，脚本连/etc/passwd都能读。信息泄露

我见过一次真实案例。某家做跨境电商的公司，整个后台管理系统的密码都硬编码在server.xml里。他们的运维图省事，直接用yum install tomcat装完就没动过默认配置。结果被一个扫站脚本扫到/examples/jsp/session.jsp，顺着参数遍历直接把数据库账号密码全扒了出来。那批数据后来在黑市上流转了至少两个月，直到有安全研究员在做威胁情报分析时才发现泄露源头。

为什么这个漏洞到现在还活着？一是Tomcat 8.5之前的版本默认启用examples，很多管理员根本不知道这个目录的存在；二是修复方式太简单——删掉webapps下的examples文件夹即可，但没人愿意为“看起来不影响业务”的事动生产环境。更讽刺的是，Apache官方从9.0.0.M1版本开始默认不再部署examples，但存量服务器依然大量存在。

检测方法其实特别粗暴。直接访问http://target:8080/examples/jsp/session.jsp，如果返回200且页面里有“Session”字样，说明漏洞存在。再试着在URL末尾加?jsp=../conf/web.xml，能看到XML文件内容就实锤了。有些老版本还能用?jsp=../../../../../../etc/passwd直接读系统文件。

修复起来也不复杂。最彻底的办法是删除整个$CATALINA_HOME/webapps/examples目录，顺便把host-manager和manager也一并删掉，这俩同样是高危入口。如果业务确实依赖这些示例代码，那就得改conf/web.xml，给/examples/*加上security-constraint，限制只允许本机访问。但说实话，真没有哪个正经业务需要依赖示例脚本，删了才是正道。

这个漏洞最坑的地方在于它不声不响。不会报错，不会影响正常功能，日志里也只有一条看似普通的GET请求。等发现的时候，往往已经被人遍历过好几轮了。建议所有还在用Tomcat 7/8老版本的系统，立刻检查一下webapps目录下有没有examples，有就删，五分钟的事，别等到被脱裤了再后悔。