备份文件暴露是什么问题
开发与运维习惯会把数据库导出、站点打包、配置文件临时命名为 .bak、.zip、.sql、.tar.gz 等放在 Web 目录下，忘记清理就形成「任何人可下载」的泄露。这类文件一旦可获取，通常直接等价于源码泄露或数据库泄露，是权限体系之外最直接的失陷路径。检查方式是：基于授权清单构造最小范围的请求，确认文件存在并判断响应大小即可下结论，不需要把文件取走。
基本信息
| 常见命名 | 文件名 + .bak/.zip/.rar/.sql/.tar.gz；站点名 + 日期 |
|---|---|
| 常见位置 | 站点根目录、备份目录、上传目录、静态资源目录 |
| 验证方式 | HEAD 请求或 GET 取前几字节，确认存在性与响应大小 |
| 处置 | 记录路径与状态码，移交客户清理 |
| 纪律 | 不下载完整文件，不查看内容 |
典型使用场景
- 信息暴露类检查中确认是否存在可下载的备份文件
- 为客户梳理部署规范问题：备份与临时文件不应留在 Web 目录
- 解释「为什么源码泄露」：多数源头是无意暴露的打包文件
- 配合目录列表暴露检查：两者常同时出现
- 验证修复效果：清理后确认路径已返回 404
核查原则
核查原则
curl -sI https://example.com/backup.zip # 用 HEAD 看状态码与内容长度
curl -s -o /dev/null -w '%{http_code} %{size_download}\n' https://example.com/db.sql
# 只比对状态码与大小，判断是否存在；不保存文件内容
# 命名尝试控制在数百次以内，不要用大字典长时间枚举
# 记录：路径 + 状态码 + 响应大小 + 时间，移交客户处置响应与判断
| 响应特征 | 含义 | 处置 |
|---|---|---|
| 200 且响应体为文件大小 | 备份文件可下载 | 列入报告，建议立即清理并评估数据影响 |
| 200 但返回站点首页 | 服务器做了统一跳转 | 不构成暴露，记录为已核查 |
| 403 禁止访问 | 文件存在但受控 | 低风险，仍建议清理 |
| 404 或 400 | 文件不存在 | 无需处置 |
确认「可下载」即是结论：取走整个备份文件既无必要，也会让测试方手中多出一份客户数据，后续处置成本更高。
枚举频率过高会触发 WAF 封禁：控制在数百次请求以内并配合限速，避免影响站点可用性与后续测试。