Apache Tomcat 默认安装后会带一个 examples 样例目录，样例很多人部署完直接跑业务，目录压根没管过它。纵漏问题就出在这儿——这个目录里的样例 Session 示例页面，如果不删，目录等于把 Session ID 的纵漏操作权交到了任何人手上。

具体来说，样例访问 /examples/servlets/servlet/SessionExample 这个路径，目录你会看到一个表单。纵漏页面上直接暴露了当前会话的样例 JSESSIONID，还允许你通过参数 name 和 value 往 Session 里塞任意属性。目录比如请求 ?纵漏name=role&value=admin，Session 里就多了一个 role=admin 的样例键值对。这本身是目录教学演示，但放在生产环境就是纵漏另一回事了。

我见过一个真实场景：某内部管理系统用的 Tomcat 8，examples 目录没清理。攻击者先访问 SessionExample 页面拿到自己的 JSESSIONID，然后构造请求往 Session 里写入 user=admin。如果后端代码恰好从 Session 里读 user 字段做权限判断，且没有做二次校验，那就直接越权了。整个过程不需要任何漏洞利用工具，浏览器地址栏就能完成。

更麻烦的是，这个页面还能读取 Session 中已有的属性。你请求 ?name=user 不带 value，页面就会把当前 Session 里 user 的值回显出来。如果系统在同一个 Session 中存了敏感信息，比如 token、用户角色、内部标识，那等于白送。

有人会说，Session 不是每个用户独立的吗？对，但漏洞的核心不在于跨用户读取，而在于攻击者可以操纵自己 Session 的内容。很多应用的权限校验逻辑是“Session 里有 admin 标记就放行”，而不是“去数据库查这个用户是不是 admin”。这种设计缺陷加上 examples 目录，就是一条完整的攻击链。

Tomcat 官方文档其实提过，examples 是给开发者学习用的，生产环境应该删除。但实际情况是，大量运维人员用 yum 或 apt 装完 Tomcat，examples 默认就在 webapps 下面。Docker 镜像更甚，很多基础镜像直接把所有默认 webapps 打包进去，用的人根本不看。

怎么确认自己有没有这个问题？直接访问 http://your-host:8080/examples/，如果能打开页面，说明目录还在。再点进 Servlets 区域找 SessionExample，能正常提交表单，那漏洞就坐实了。

修复方式没什么技术含量：rm -rf webapps/examples，完事。如果不想删整个目录，至少把 examples/WEB-INF/web.xml 里 servlet 映射注释掉，或者直接在 conf/Catalina/localhost 下建一个 examples.xml 把 Context 的 docBase 指向一个空目录。但最省心的还是删掉，留着没有任何好处。

另外提一句，Tomcat 7 之后的版本默认安装包里 examples 是单独的可选组件，但很多第三方打包版本仍然包含。别假设你的 Tomcat 没有，花十秒钟访问一下那个 URL，比事后补救划算得多。

这个漏洞严格来说不算 Tomcat 的锅，它只是提供了一个演示功能。但安全这件事，默认配置往往就是最大的风险面。一个教学用的 Session 示例，放到公网服务器上，就是一把没上锁的门。