Apache Tomcat示例脚本信息泄露漏洞

去年我帮朋友排查一个线上问题，他用Tomcat 9跑了个小项目，脚本结果在Google上搜自己域名，信息泄露搜出来一堆本该被删掉的漏洞/examples/servlets/servlet/RequestParamExample页面，里面清清楚楚列着用户提交的示例表单数据。他当时就懵了——这玩意儿不是脚本装完Tomcat就自带的吗？怎么还能被搜索引擎爬到？

这事其实不新鲜。Tomcat默认安装包里一直带着examples这个目录，信息泄露里面塞满了各种演示用的漏洞JSP和Servlet。本来目的示例是让开发者快速上手，但现实是脚本，绝大多数人部署完应用之后根本不会去动它。信息泄露更糟的漏洞是，很多生产环境的示例Tomcat直接暴露在公网，webapps下的脚本examples文件夹原封不动，谁都能访问。信息泄露

问题出在哪儿？这些示例脚本里有一批会回显用户输入。比如RequestParamExample，你传个?name=test，它就把test原样打在页面上。再比如CookieExample，会把你的Cookie值直接输出。单独看好像没什么，但要是攻击者构造一个带恶意脚本的URL，诱导别人点击，那就是反射型XSS。更隐蔽的是，这些页面有时会暴露服务器内部路径、类名、版本信息——等于给攻击者递了张地图。

 # 典型的泄露路径 http://target:8080/examples/servlets/servlet/RequestParamExample http://target:8080/examples/jsp/jsp2/el/basic-arithmetic.jsp http://target:8080/examples/websocket/echo.xhtml 

我见过最离谱的一个案例，某公司内网Tomcat的/examples/jsp/num/numguess.jsp没删，结果被人通过这个页面猜到了数据库连接池的JNDI名称，虽然后续利用需要其他条件配合，但信息泄露的链条往往就是这么一环扣一环。你永远不知道攻击者会把一个看似无害的示例页面和哪个漏洞组合起来。

有人会说，那我装完Tomcat手动删掉webapps/examples不就行了？对，这是标准操作。可现实是，大量Docker镜像、云市场里的Tomcat模板、甚至某些“一键部署”脚本，都默认保留了这个目录。我查过几个流行的Tomcat基础镜像，至少有两个版本在docker run之后examples还在。开发者以为镜像已经“优化”过了，实际上并没有。

另一个容易被忽略的点：即使你删了webapps/examples，conf/Catalina/localhost下可能还残留着examples.xml上下文配置文件。Tomcat启动时会去加载它，如果对应的docBase路径不存在，一般只是报个警告，但要是路径被恶意指向别处……那就不是信息泄露那么简单了。所以清理要彻底，webapps和conf下的相关文件都得处理。

那怎么判断自己有没有中招？直接访问http://你的域名:端口/examples/，如果返回403或者404，基本安全。如果返回一个目录列表或者跳转到某个示例页面，那就得赶紧动手了。别指望WAF能拦住所有变种，我试过用URL编码绕过某些规则，照样能读到RequestParamExample的页面内容。

修复方案没什么花哨的：删掉webapps/examples整个目录；检查conf/server.xml里有没有多余的Context配置指向示例；如果用了Tomcat Manager，确保它只监听内网或者加了强认证。另外，升级到最新版Tomcat也有帮助——新版本里示例脚本本身做了一些输入过滤，但根子还在，删掉才是最干净的。

写这些不是要制造恐慌。Tomcat是个好东西，示例脚本本身也没恶意。问题在于“默认配置”和“生产环境”之间的鸿沟，太多人直接跨过去了，连看都没看一眼。下次部署完Tomcat，花三十秒执行rm -rf webapps/examples，能省掉后面一堆麻烦事。

(责任编辑：百科)