1. WEB-INF/web.xmlJava Web应用的安全命门第一次接触WEB-INF目录是在一次内部渗透测试中。当时测试目标是一个电商系统在尝试访问/WEB-INF/web.xml时服务器竟然直接返回了这个配置文件的内容——这个意外发现让我意识到很多开发团队对Java Web基础安全配置的重视程度远远不够。WEB-INF目录是Java Web应用的标准安全目录相当于一个保险箱。按照规范这个目录下的所有资源都不应该被客户端直接访问。但现实情况是由于服务器配置不当这个保险箱经常处于敞开状态。让我们看看这个目录的典型结构/WEB-INF/ ├── web.xml # 核心配置文件包含Servlet映射、过滤器配置等 ├── classes/ # 编译后的class文件按包结构存放 ├── lib/ # 依赖的JAR库文件 └── src/ # 源代码目录部分项目会存放最危险的泄露点往往是web.xml文件。这个文件就像整个应用的地图记录了所有关键组件的部署信息。去年审计某金融系统时我们通过泄露的web.xml发现了内部接口的鉴权绕过漏洞——因为文件里清楚标注了security-constraint配置的URL模式。2. 漏洞成因配置失误的连锁反应为什么理论上应该被严格保护的目录会暴露根本原因在于多层架构的配置断层。现代Java Web应用通常采用NginxTomcat的组合架构而问题往往出在两者的配置协同上。2.1 典型错误配置场景我遇到过最经典的案例是某企业的CRM系统。他们的Nginx配置是这样的location ~* \.(jsp|do|action)$ { proxy_pass http://tomcat_backend; } location / { root /data/webapp/; try_files $uri $uri/ 404; }这种配置下当请求/WEB-INF/web.xml时Nginx发现不是动态请求不符合第一个location尝试在静态资源目录查找文件第二个location生效由于没有访问限制直接返回文件内容关键问题在于Nginx作为反向代理时默认不会继承Tomcat的安全规则。Tomcat虽然会保护WEB-INF但请求根本就没到达Tomcat2.2 其他常见暴露途径除了反向代理配置问题这些情况也会导致泄露目录穿越漏洞通过../../跳转目录文件包含漏洞通过参数动态包含文件备份文件泄露如web.xml.bak未删除中间件漏洞如Jetty的CVE-2021-28164去年在渗透测试某政务系统时我们发现其存在文件下载功能通过构造filename../../../WEB-INF/web.xml成功获取到配置文件。这种漏洞在老旧系统中尤为常见。3. 攻击链构建从信息泄露到系统沦陷通过web.xml泄露能发起怎样的攻击让我们通过一个真实案例还原完整的攻击链。3.1 案例某物流平台渗透过程第一阶段信息收集发现/static/../WEB-INF/web.xml可访问从中获取到关键Servlet配置servlet servlet-nameExportServlet/servlet-name servlet-classcom.logistics.export.ExportController/servlet-class /servlet第二阶段定位业务逻辑根据类名推断class文件路径/WEB-INF/classes/com/logistics/export/ExportController.class通过相同漏洞下载该class文件使用JD-GUI反编译获取源码第三阶段漏洞挖掘分析源码发现未授权访问漏洞public void doGet(HttpServletRequest req, HttpServletResponse resp) { String type req.getParameter(type); // 缺失权限校验 exportData(type); }第四阶段获取数据构造请求直接导出所有订单数据GET /export?typeallOrders HTTP/1.13.2 自动化利用工具对于这类漏洞安全研究人员常用工具包括WebPathBrute目录爆破工具JD-GUIJava反编译器Burp Suite手动测试时用于构造特殊请求这是我常用的检测payload清单/WEB-INF/web.xml /%57%45%42%2d%49%4e%46/web.xml # URL编码绕过 /static/../../WEB-INF/web.xml # 路径遍历4. 防御方案多层次防护体系基于多年实战经验我总结出以下防御策略按照实施优先级排序4.1 基础设施层防护Nginx配置示例location ~ ^/WEB-INF { deny all; return 404; } location ~* \.(xml|properties)$ { deny all; }Tomcat配置要点在conf/web.xml中确保security-constraint web-resource-collection url-pattern/WEB-INF/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint4.2 应用层防护代码审查重点检查所有文件操作API如FileInputStream禁止动态拼接文件路径使用getCanonicalPath()校验路径安全编码示例// 不安全的写法 String file request.getParameter(file); File f new File(/data/ file); // 安全的写法 Path safeBase Paths.get(/data).normalize(); Path userPath Paths.get(file).normalize(); if (!userPath.startsWith(safeBase)) { throw new SecurityException(非法路径); }4.3 监控与应急在WAF中配置规则拦截包含WEB-INF的URL请求异常的../序列.class文件下载请求日志监控关键词WEB-INFClassNotFoundException异常的200状态码返回.xml/.class文件5. 渗透测试实战技巧在最近一次金融行业红队行动中我们发现通过WEB-INF泄露可以挖掘出更多漏洞5.1 进阶信息收集数据库配置挖掘 查找web.xml中的context-param param-namejdbcUrl/param-name param-valuejdbc:mysql://10.0.0.1:3306/core_db/param-value /context-paramSpring框架识别 通过DispatcherServlet配置判断框架类型servlet servlet-namespring/servlet-name servlet-classorg.springframework.web.servlet.DispatcherServlet/servlet-class /servlet5.2 漏洞组合利用某次测试中我们结合WEB-INF泄露与文件上传漏洞实现了RCE通过web.xml发现使用了Apache Commons FileUpload分析上传逻辑找到文件名截断漏洞上传.jsp文件但命名为shell.jsp\x00.jpg通过路径遍历执行上传的shell5.3 隐蔽测试方法为避免触发WAF可以尝试编码绕过/%57%45%42%2d%49%4e%46/web.xml参数污染/download?fileWEB-INF/web.xmltoken123HTTP方法切换 有些系统GET方法被拦截但POST可能允许6. 企业级防护建议对于大型企业我建议采取以下深度防御措施架构层面使用WAFAPI网关双重防护静态资源与动态应用分离部署敏感目录设置独立的访问策略开发流程graph TD A[需求设计] -- B[威胁建模] B -- C[安全编码] C -- D[自动化扫描] D -- E[人工审计] E -- F[渗透测试]安全基线检查项[ ] WEB-INF目录访问测试[ ] 配置文件敏感信息检查[ ] 文件操作API审计[ ] 异常路径处理测试7. 从防御到攻击红队视角的思考站在攻击者角度WEB-INF泄露的价值不仅在于获取配置信息更重要的是理解应用架构。通过分析web.xml我们可以绘制应用的功能模块图识别使用的第三方组件及其版本推测业务逻辑的处理流程定位潜在的未授权访问点在某次攻防演练中我们通过分析filter-mapping配置发现某个管理接口被错误配置为不鉴权直接绕过了整个权限体系。这种深层次的架构理解往往比单纯的漏洞扫描更有杀伤力。8. 法律与道德边界需要特别强调的是所有安全测试必须遵守获得明确的书面授权不进行实际数据窃取测试后完整清理痕迹发现漏洞后及时报告去年某次测试中我们发现客户系统存在严重配置问题在验证漏洞存在后立即停止测试并提供了详细的修复方案。这才是专业安全人员应有的操守。