做授权渗透测试或者企业安全巡检时我最深的体会是信息收集这一阶段做得扎不扎实直接决定后续测试能走多远。有一次目标只有一个登录框常规漏扫跑了一天没结果我改用 dirsearch 挂上一份中大型字典扫了几分钟就找到/backup.zip下载回来直接是整站源码管理员口令就硬编码在里面。整个过程不到十分钟却比前面两天的盲目尝试都有效。这就是目录扫描和敏感目录泄露挖掘的价值它不直接给你一个 shell却能经常把“看上去很难测”的目标变成一场填空题。这篇文章围绕 dirsearch、字典爆破、敏感目录泄露挖掘这三个点把工具原理、字典构造、实际扫描和分析思路讲透。适合正在学 Web 安全、做安全测试的工程师也适合想排查自家站点是否存在敏感目录暴露的运维同学。前提只有一条所有操作务必在授权目标上进行。1. 目录扫描到底在扫什么敏感目录泄露的价值拆解1.1 一个容易被低估的信息收集手段目录扫描的本质是向 Web 服务器批量发送 HTTP 请求探测页面上没有公开出来的文件和目录。很多人刚接触时觉得它就是把字典里的路径挨个请求一遍没什么技术含量。但真正做过目标测试的人都明白Web 应用的暴露面远不止首页导航菜单上的那几个入口。开发调试留下的备份文件、版本控制目录、配置文件、日志文件、临时上传目录这些东西通常没有入口链接搜索引擎也不一定收录但它们恰恰是测试中最容易撕开的口子。敏感目录泄露的形态其实很多。最常见的是备份文件比如backup.zip、wwwroot.tar.gz、web.sql很多管理员把整个站点打包放在 Web 根目录后忘了删除结果变成了公开下载的资源。其次是版本控制目录.git/在大量开发机上被直接暴露通过工具可以恢复源码、提交记录甚至从历史提交里翻出密码。配置类文件也是重灾区.env、config.php.bak、web.config.old里面通常有数据库账号、密钥、第三方 API Key。还有运维遗留文件比如info.php、test/、logs/能把环境信息和目录结构直接暴露给访问者。最后是框架路由和接口文档swagger-ui.html、actuator/、api-docs这类路径一旦开放等于给测试方画好了一张攻击面地图。这些内容单看一个可能只是“信息泄露”但串起来之后影响范围往往覆盖整站源码、数据库口令、云平台密钥严重程度不亚于直接拿下一个漏洞。1.2 为什么目录扫描应该尽早做在信息收集阶段目录扫描的执行顺序其实有讲究。一般流程是先做子域名枚举和端口发现搞清楚资产范围紧接着就应该做目录扫描。它比端口扫描更接近业务逻辑比漏洞扫描更快出结果而且获得的路径线索不会因为 IP 或端口变化而失效。目录路径是开发者之间约定俗成的东西判断起来非常快。比如很多 Java 项目默认保留actuator端点很多 PHP 项目会残留phpmyadmin很多 Windows 服务器会暴露/iisstart.htm或/test.asp。通过这些路径可以快速反推技术栈和框架版本为后续漏洞发掘缩小范围。一个只有登录框的目标端口扫描可能只看到 80 和 443漏洞扫描也可能颗粒无收但目录扫描经常能扫出后台入口、文件上传点、接口文档直接改变整个测试计划。简单说目录扫描应该放在漏洞扫描之前而不是之后因为它的产出是“路径”而漏洞扫描的产出是“漏洞”先有路径才谈得上深入测试。1.3 网络上常提的三类工具dirsearch、御剑、Burp Suite搜索目录扫描相关资料时经常看到三样东西dirsearch、御剑目录扫描、Burp Suite 爆破字典。它们定位不同适合的阶段也不一样。dirsearch 是跨平台命令行工具字典丰富支持递归扫描、多线程、自定义扩展名还能输出 JSON/CSV 报告很适合自动化流程。御剑目录扫描是 Windows 下的经典 GUI 工具内置了常用的国内站点路径字典界面简单点一下“开始”就能跑适合快速验证单个目标。Burp Suite 的 Intruder 模块本身就能做目录枚举和参数爆破新版还有 Content Discovery 功能底层逻辑同样是字典请求。实际测试中我更习惯用 dirsearch 做第一轮全量扫描用御剑的内置字典做补充再用 Burp 对命中的后台目录做定向枚举和接口分析。三者不是互相替代的关系而是覆盖了不同的字典偏好和操作习惯。2. dirsearch 安装与配置从 apt 报错到核心参数心得2.1 解决 unable to locate package dirsearch在 Kali 或 Ubuntu 上安装 dirsearch很多人第一反应是执行apt install dirsearch然后系统返回一行unable to locate package dirsearch。这个报错在新装的系统上出现概率很高原因有两类一是没有更新软件包索引软件源里暂时搜不到这个包名二是当前发行版的官方仓库里没有收录 dirsearch。第一步先执行sudo apt update更新索引然后重新安装试试。如果依然报错就说明仓库里确实没有需要换安装方式。我推荐的方式是直接克隆官方仓库这样既能保证版本最新也方便后续更新。git clone https://github.com/maurosoria/dirsearch.git cd dirsearch python3 dirsearch.py -hdirsearch 的依赖非常少Python 3 环境基本都自带所需标准库克隆下来就能直接运行。也可以使用 pip 安装pip install dirsearch装好后直接用dirsearch -h命令调用。但 pip 安装的版本有时候更新不及时我习惯保留 Git 目录每周git pull拉一次更新。新版工具在状态码过滤、递归扫描、响应大小比对这几个方向改进很明显值得保持更新。2.2 常用参数与真实用法dirsearch 的参数非常多但真正高频使用的也就十几个。最常用的组合是这样的python3 dirsearch.py -u https://example.com -e php,txt,bak,zip -t 50 --random-agent -x 404,403 -o result.json简单解释一下每个参数的含义-u指定目标 URL注意要带协议头。-e指定扩展名列表用逗号分隔上面这条命令会让工具自动去请求index.php、index.txt、index.bak、index.zip这一类路径。-t线程数默认是 25这里调到 50 是为了对普通目标提速。--random-agent为每个请求随机设置 User-Agent减少被安全设备按特征拦截的概率。-x排除不希望看到的状态码。排除 403 是因为不少服务器对不存在的统一回 403排除 404 是避免无效结果刷屏。-o输出文件建议输出为 JSON 格式后面做筛选和报告很方便。扫描结果里每一行会显示状态码、响应大小、路径和重定向目标。看到 200 的路径不要急着欢呼先看内容长度和标题后面我会专门讲怎么验证误报。还可以用--recursive开启递归扫描也就是扫到admin/之后自动进入admin/目录继续跑字典--deep-recursive是更深的递归适合对封禁不那么严格的目标使用。我通常不会一上来就开递归而是先跑完第一轮人工确认有保留价值的目录后再针对这些目录单独跑一轮递归这样效率更高。2.3 线程、超时与性能平衡线程数不是越大越好。-t 50对普通目标也许很快但目标如果是老旧的 Windows 服务器或者托管在配置很低的 VPS 上请求稍微多起来可能直接把目标跑挂这在生产环境上是事故。我的习惯是先-t 20起步跑一分钟看响应时间如果目标没有任何卡顿再逐步加到 50 甚至 100。如果响应时间明显变长立刻降回到 20。超时参数的调整也容易被忽略。网络环境不稳定时某些路径请求会超时工具默认把它当作不存在或错误处理这会带来漏报。dirsearch 的较新版本支持通过--timeout调整超时时间我通常设为 10 秒左右既能避免长时间等待也能减少慢响应导致的误报。如果目标用了 CDN延迟本身可能就偏高超时设得太短会漏掉不少真实路径。另一个实用参数是--rate用来限制每秒请求数。对生产环境做巡检时--rate 20比一味拉高线程数要稳妥得多虽然慢一点但不会打爆目标。3. 字典爆破原理解密不是拿个大字典就完事3.1 为什么目录扫描本质是字典爆破所谓目录爆破本质上是对字典里的路径批量发起 HTTP 请求再根据响应状态码判断路径是否存在。状态码是核心线索常见的判断逻辑可以整理成一张表。状态码含义目录扫描时的判断200请求成功路径大概率存在重点验证内容301/302重定向路径存在需要继续分析 Location 头401需要身份认证路径存在可能通过认证绕过进一步测试403禁止访问路径存在但被拒绝值得记录和后续绕过404页面不存在基本可排除500服务器内部错误路径或参数触发了异常值得记录这份判断表是工具筛选结果的底层逻辑。很多新手喜欢一上来就拖一个几十万行的巨型字典扫到天荒地老结果有效结果就三两行既浪费资源又容易触发安全告警。真正高效的做法是结合目标实际情况来选字典。常见的公开字典有三类SecLists 的Discovery/Web-Content目录它对常用文件名、备份文件、目录名、参数名做了很细的分类适合深入研究DirBuster 自带的directory-list-lowercase-2.3-medium.txt大约 22 万条适合大型目标的全量枚举dirsearch 自带的db/dicc.txt覆盖了常见路径平时快速验证已经够用。如果目标是国内建站系统建议再准备一份中文 CMS 后台路径字典比如dedecms、phpcms、帝国CMS的后台目录这些在国内资产的测试中命中率相当高。3.2 扩展名参数为什么不能乱填-e参数对扫描结果的影响比很多人想象的要大。它的原理是工具拿到字典里的每个词根后会分别与各扩展名拼接。比如字典里有config指定-e php,txt,bak,zip后会产生config.php、config.txt、config.bak、config.zip四个请求。扩展名配得越多请求量成倍增长扩展名配得不准可能漏掉真实存在的文件。因此扩展名一定要按技术栈来选。目标指纹是 PHP就优先加php,bak,txt,zip,sql目标指纹是 Java要加jsp,do,action,json,xml前端项目重点看js,map,json。有一种更精细的玩法是分两轮扫描第一轮不加扩展名只扫纯目录和纯文件名第二轮针对第一轮的命中结果结合技术栈加扩展名。dirsearch 新版还支持在字典里使用%EXT%这种占位符告诉工具在指定位置替换扩展名适合字典作者做精细控制。对大多数使用者来说直接用-e就够了。3.3 字典的裁剪、合并与 Burp Suite 互补字典不是越大越好关键是路径质量。我每次扫描前会先识别一下目标使用的框架用 Wappalyzer 或简单的响应头判断然后只扫描对应框架的路径字典而不是上来就全量扫。实际操作中我经常把多个字典合并去重用sort -u处理后再按“常见后台路径 技术栈特征文件 备份残留”三部分自定义一份精简字典。举个例子如果目标是 WordPress 站点我会把wp-admin、wp-content、wp-config.php.bak、xmlrpc.php这类路径放进第一优先级。如果目标是 Spring Boot重点扫actuator、swagger-ui.html、api-docs、env。一份 20 到 50 条的高命中自定义字典往往比 20000 条泛用字典更有价值因为扫描在几分钟内结束特征路径却全部命中。这也是为什么我建议不要只依赖单一字典。Burp Suite 爆破字典在这里的角色更像“补刀”。当 dirsearch 找到/admin目录后可以用 Burp 的 Intruder 模块继续对/admin/login.php做参数枚举或者针对子目录做二次目录枚举。反过来用 Burp 抓取目标页面里的静态资源路径、接口路径把这些路径清洗后加入自定义字典再回到 dirsearch 里跑一轮往往能发现开发者没有暴露在页面上的文件。免费版 Intruder 有请求速率限制但这正好能避免对目标产生过大压力也不算坏事。4. 敏感目录泄露挖掘实操一个完整流程4.1 扫描前的授权确认与信息先导无论做任何测试第一步永远是确认授权。个人学习目标可以使用自己搭的靶机商业项目必须有书面委托。在这个前提下我在扫描前会先查看两个文件robots.txt和sitemap.xml。很多站点把不允许搜索引擎收录的路径写在 robots.txt 里这等于免费送了一份路径字典。虽然 robots.txt 只是声明不代表真正的访问控制但它能快速告诉我哪些路径是站长不想公开的重点盯这些路径往往有惊喜。接下来看响应头。Server字段能显示 Web 服务器类型X-Powered-By经常暴露 PHP 或 ASP.NETSet-Cookie里的参数名能辅助判断后端框架。这些信息决定了字典扩展名要怎么配也决定了后续扫描优先关注哪类敏感文件。这一步做完才轮到目录扫描器上场。4.2 实战命令从基础扫描到递归挖掘以一个授权测试的 PHP 站点为例。基础扫描命令python3 dirsearch.py -u https://example.com -e php,bak,zip,txt -t 30 --random-agent -x 404,403 -o first_round.json假设结果里出现了/.git/HEAD状态码 200内容是一行ref: refs/heads/master这就是典型的 Git 泄露。dirsearch 的任务到这里并没有结束我通常会再针对.git目录做一轮定向探测看.git/config、.git/index、.git/logs/HEAD是否也可访问。只要这些对象能读就能用git-dumper或GitHack这类脚本把源码拉下来然后进入代码审计阶段。再假设结果里出现了/swagger-ui.html状态码 200标题是 Swagger UI说明目标暴露了 API 文档。这时候目录扫描的后续动作就变成了收集接口列表然后逐个测未授权访问、参数校验和越权。很多企业内部系统在 Nginx 里忘了屏蔽 Swagger扫到这种路径比扫到几十个普通备份文件的价值都高因为它直接暴露了可调用的业务接口。4.3 响应状态码的误判与内容验证目录扫描输出里的 200 并不等于目录或文件真实存在。现在很多前后端分离项目会用try_files把所有路径回退到首页导致任何不存在的路径都返回 200扫描结果里出现一片假阳性。验证方法有三个第一看响应大小如果大量 200 路径的Content-Length完全一样大概率都返回了同一个首页第二看页面标题工具输出里通常会显示标题如果一堆路径的标题都是网站首页标题说明被回退规则干扰了第三找一个肯定不存在的随机路径做对照比如请求/nonexistent-abc123.html如果它同样返回 200那么这次扫描的 200 结果就要整体打折。dirsearch 新版本提供了--exclude-content-length和--exclude-content-type参数可以排除指定大小或类型的响应。我更常用的做法是把结果保存为 JSON然后写一段脚本按状态码、Content-Length、响应标题做二次筛选。有一次目标把所有错误请求统一 301 跳转到首页我一开始为了省事排除了 301结果漏掉了一堆真实路径。后来从 Burp 里看到跳转地址才意识到某些中间件在路径存在时会通过 301 跳到规范化地址而路径不存在时会跳到首页。这个细节提醒我排除状态码之前一定要先小范围验证其语义不能想当然。4.4 敏感文件里到底藏着什么把扫描结果梳理之后需要按资产类型分类评估。不同类型的敏感文件对应不同风险和后续利用方式版本控制目录.git、.svn可恢复源码、数据库配置、提交记录是严重的信息泄露。备份压缩包.zip、.tar.gz、.sql可以直接拖库或拖源码审计硬编码口令。目录浏览Index of /Apache/Nginx 的目录列表功能开启后能看到目录下所有文件优先找上传目录和管理目录。配置文件.env、config.php.bak大多包含数据库口令、App Secret、OSS 密钥。测试脚本test.php、info.php、phpinfo.php泄露绝对路径、已加载模块和运行环境方便后续利用。API 文档swagger-ui.html、api-docs接口清单是未授权测试的地图。前端源码映射文件.js.map可以还原出 TypeScript 源码和业务逻辑。macOS 遗留文件.DS_Store在 macOS 部署时自动生成可以解析出目录下文件名列表。这些敏感文件中尤其要关注.env文件。很多框架会把环境变量集中放在.env里内容包括数据库地址、账号、密码、应用密钥、邮件服务凭据。一旦通过目录扫描发现该文件可访问直接curl拉取内容很多情况下就能直接登录数据库或后台。备份压缩包的危害更直接解压后就是整站代码配合源码审计可以快速定位高危漏洞。5. 常见问题与排查技巧实录5.1 安装和启动报错排查遇到过最多的安装报错就是unable to locate package dirsearch解决办法前面已经说了优先apt update不行就 Git 克隆。还有一类报错发生在 Python 环境不太干净的机器上提示ModuleNotFoundError: No module named dirsearch这通常是 pip 安装路径没有加入环境变量可以用python3 -m pip install --user dirsearch重装到当前用户目录避免系统环境的权限干扰。Windows 下运行 dirsearch 还可能出现中文乱码因为默认编码可能是 GBK而工具输出的是 UTF-8。在 CMD 里先执行chcp 65001切换到 UTF-8 编码就能解决。如果想省事直接用 Windows Terminal 或 VS Code 的集成终端基本不会有编码问题。5.2 误报、状态码和 CDN 干扰误报是目录扫描最常见的困扰。除了前面说到的软 404还有几种情况要注意。第一种是 403 状态码有些服务器对所有不允许访问的路径都统一返回 403即使路径不存在。判断方法是用一个随机路径请求一下如果也返回 403说明存在全局拦截规则扫描的 403 结果价值不大。第二种是 302 重定向路径存在和路径不存在可能都跳到登录页需要对比 Location 头和跳转后的内容。第三种是 CDN 干扰源站和 CDN 节点对路径的处理策略可能不一致比如 CDN 对某些路径做了缓存返回 200 但内容内容其实是缓存页这时候最好直接绑定 Host 到源站 IP 扫描或者用小范围路径验证。应对这些干扰关键是保留原始响应数据。dirsearch 支持输出 JSON 和 CSV我会把每次扫描的原始结果完整保留方便后续二次分析。就算工具当前版本不支持某些过滤条件也可以导出后用脚本处理避免反复扫描目标。5.3 扫描结果的留存与自动化在企业安全巡检中目录扫描不能只作为一次性的测试动作还要形成可复用的资产风险记录。我习惯把每次结果保存成 JSON 和 CSV 两份JSON 方便脚本处理CSV 方便写报告时引用。对于大型目标还会用目录扫描的发现去驱动下一轮信息收集例如把/.git/config的发现标记为“高危事件”导入漏洞管理平台把/swagger-ui.html的发现汇总为“攻击面清单”。如果是定期巡检可以写一个简单的定时任务每周对关键资产自动跑一遍 dirsearch使用精简字典并结合状态码变化和新增路径来发现新的风险点。扫描结果写入数据库后还能和资产指纹做关联自动按“是否属于重要系统”“是否开启敏感接口”分级告警。需要注意的是自动化扫描会影响业务日志和 WAF 告警建议在业务低峰期执行并且控制线程和请求速率。5.4 多工具交叉验证的小习惯最后分享一个我坚持了很久的实务习惯不依赖单一工具。dirsearch 扫完我会用御剑再跑一份国内常见后台字典然后对命中的路径用 Burp 的 Intruder 做参数枚举和二次目录枚举。多工具交叉的目的不是重复劳动而是覆盖不同的字典偏好。dirsearch 自带的字典偏重国外开源项目命名习惯御剑内置的字典对国内 CMS 和建站系统更友好两者结合再加上一份 SecLists 做补充基本能覆盖大多数敏感目录泄露场景。但这个习惯也有一个代价就是扫描结果量会非常大。我通常会在工具输出后先按状态码和响应大小做一次粗筛把明显无意义的路径去掉再逐个验证剩余的潜在目标。验证时多用 Burp 的抓包功能直接看响应头、响应体里的关键字段而不是只看工具给的标题和大小。无论扫出什么结果也不要忘记最初的授权边界只在授权范围内的目标上做测试否则目录扫描这个技术点上积累的经验反而会带来不必要的风险。