做安全评估这些年，我最深的感受是：很多看似固若金汤的系统，最后突破口往往不是0day，而是一个没人注意的备份文件。今天想和你认真聊聊我在实际项目中一直在用的目录扫描三件套：dirsearch工具、字典爆破手段、以及如何从扫描结果里发现敏感目录泄露的蛛丝马迹。这篇文章不会只贴命令，我会把为什么这样做、踩过哪些坑、扫描结果怎么看，都摊开来说清楚。无论你是刚入门的安全爱好者，还是需要做自查的运维/开发同学，都能从中找到可以直接上手的东西。
1. 敏感目录泄露：被低估的Web安全盲区
1.1 那个藏在备份文件里的数据库配置
先说个真实经历。去年我参与一个授权范围内的安全评估项目，目标站点的Web应用本身防护做得相当不错，常规注入点、上传点都没有可利用的洞。就在大家准备收工的时候，我在站点域名后面加了个/backup/，然后跑了一轮目录扫描。结果在返回的200状态码列表里，发现一个site_backup_202409.zip，将近40MB。下载解压后，里面除了源码，还躺着一个config/database.php，数据库地址、账号、密码全部明文。
这个被忽视的备份文件，直接让整个测试深度提升了一个级别。后来跟开发复盘时发现，这个文件是运维同学在升级前随手打包放在web目录下的，想着“临时放一下”，结果一放就是大半年。说实话，这类情况在真实环境里太常见了，这也是为什么我一直坚持：目录扫描不是可选步骤，而是信息收集阶段必做的基础动作。
1.2 敏感目录泄露的典型类型
用一张表把常见泄露类型说清楚，也好在扫描时有的放矢。
| 类型 | 常见文件名/路径 | 风险等级 |
|---|---|---|
| 备份压缩包 | .zip、.tar.gz、.bak、backup/、www.zip | 高，可能包含源码和配置 |
| 源码仓库残留 | .git/、.svn/、.hg/ | 高，可通过工具还原源码 |
| 临时文件 | .swp、~结束的文件、.old、.temp | 中，可能泄露编辑中的代码 |
| 配置文件 | .env、config.php.bak、settings.py、web.config | 高，直接泄露密钥/连接串 |
| 日志文件 | access.log、error.log、runtime/log/ | 中，泄露访问记录、参数 |
| 管理后台入口 | /admin、/manage、/login、/console | 中，扩大攻击面 |
| 测试脚本 | phpinfo.php、test.php、info.php、demo.php | 中，泄露环境信息 |
这些泄露的本质，都是**“不该被web目录暴露的东西，被放进了web根目录”**。目录扫描工具做的就是主动去探测这些“不该存在”的路径是否真的存在。
1.3 目录扫描在安全评估流程里的位置
很多刚接触安全测试的朋友会有个误区：拿到目标就直接上漏扫，扫完复制报告就完事。但漏扫和目录扫描解决的问题不一样。漏扫器会把重点放在已发现页面的参数、组件版本漏洞上；而目录扫描做的是路径层面的发现，它帮你把整个站点的“地图”画出来。很多漏扫器发现不了的问题——比如未公开的测试接口、遗留的备份包、隐藏的后台地址——恰恰是目录扫描最容易捞到的。
所以我的习惯是：先指纹识别，再目录扫描，最后再做针对性漏扫。顺序不能乱，指纹决定了字典怎么选，字典又决定了扫描结果的上限。
2. dirsearch安装三连：从报错到跑通的完整过程
2.1 为什么一上来会遇到"unable to locate package dirsearch"
很多朋友习惯用系统包管理器装工具，第一反应就是sudo apt install dirsearch。在Kali上这一般没问题，但对用Ubuntu、Debian或者自己服务器做测试的同学来说，经常会在这一步看到一行红字：
unable to locate package dirsearch这里先解释清楚：不是你的网络问题，也不是工具不存在，而是默认的软件源里没有收录dirsearch这个包。Debian系发行版的软件包收录有自己的节奏，目录扫描这类安全工具未必都在官方源里。遇到这个报错，有些人会去折腾apt源，反而绕了远路。dirsearch的官方推荐方式本来就是从GitHub仓库运行，没必要在包管理器这条路上死磕。
2.2 最可靠的安装路径：git clone + pip 依赖
我的标准做法是源码运行，步骤不复杂，顺手把依赖也装好。
# 1. 确认 Python3 和 Git 已安装 python3 --version git --version # 2. 克隆 dirsearch 仓库 git clone https://github.com/maurosoria/dirsearch.git # 3. 进入目录并安装依赖 cd dirsearch pip3 install -r requirements.txt # 4. 验证能否运行 python3 dirsearch.py --version依赖这一层很多人会忽略。dirsearch依赖若干第三方Python库，比如requests、certifi、colorama等。如果直接运行python3 dirsearch.py -h报错提示缺少某个Module，就是requirements.txt没装好。用pip3 install -r requirements.txt一次性装完是最省事的。
提示：如果当前环境存在多个Python版本，记得确认
pip3对应的是你要用的那个Python3。否则可能出现“有requests但还是提示ImportError”的精分现场。
装好之后，跑一条最简单的命令做自检：
python3 dirsearch.py -u http://testphp.vulnweb.com -e php能正常扫出一个列表，就说明环境没问题了。第一次跑的时候注意看终端的输出格式，它会把状态码、响应大小、目标URL分颜色展示，这套输出规则后续在筛结果时会反复用到。
2.3 版本升级与工具目录管理
从GitHub克隆的方式还有个好处：升级方便。在仓库目录里执行：
git pull即可更新到最新版本。在真实项目中，我通常会在自己的工具目录下建立一个tools/文件夹，所有这类命令行走的工具都放在一起，避免散落在各个临时目录里找不到。另外建议养成一个好习惯：不要直接修改原工具目录下的默认字典，把自定义字典单独放一个目录，这样每次升级工具代码或者更新仓库时，自己的字典资产不会被冲掉。
3. 六个扫描参数，决定目录扫描的最终质量
3.1 基础组合：-u、-w、-e
先看一个最典型的用法：
python3 dirsearch.py -u https://target.com -w /path/to/dict.txt -e php,html,bak三个参数分别表示：目标URL、字典文件、追加扩展名。这里重点说下-e。dirsearch扫描时，会对字典里的每个路径尝试追加这些后缀。比如字典里有一条admin，加上-e php,bak后，工具会同时探测admin、admin.php、admin.bak三条路径。
实际扫描时，扩展名的选择要跟着站点技术栈走。如果指纹识别发现目标用PHP，就带上php；看到ASPX，就带aspx；看到Spring Boot，多关注json、yml这类配置文件后缀。为了省时间，我一般第一轮只带上最可能的1-2个后缀，第二轮再追加其他后缀扫一遍。
3.2 并发与速率的平衡：-t 与 --delay
python3 dirsearch.py -u https://target.com -t 30 --delay=0.5-t指定线程数，--delay是每个请求之间的延迟时间。新手上来喜欢把线程拉到100，觉得扫得快就完事了。但线程过高会带来两个现实问题：
- 目标服务器扛不住，直接触发WAF把IP封掉，导致后半段全部是误报或超时；
- 扫描本身会产生大量并发请求，有可能对目标业务造成实际影响。在授权测试里，这属于非常不专业的做法。
我自己的经验是：普通中小站点，线程20-30足够；目标较稳或者带宽有限，降到10；如果遇到WAF，直接加--delay=1甚至更大，把请求频率降下来，宁可扫慢一点，也要保证扫描结果可信。目录扫描比的是结果质量，不是耗时长短。
3.3 递归扫描：-r 和 --max-recursion-depth
python3 dirsearch.py -u https://target.com -r -R 2-r开启递归扫描：当发现一个目录后，会继续在这个目录内部跑一遍字典；-R控制最大递归深度。举例子：发现/admin/目录，递归扫描会继续探测/admin/login.php、/admin/config.bak这类深层路径。
但这个功能需要谨慎开启。递归会把扫描时间变成指数级增长，而且很容易把深层目录里的噪音也扫出来。我的建议是：第一轮全站扫描不开递归，先拿浅层路径；拿到结果后，对感兴趣的目录单独用-r再扫一遍。比如：
python3 dirsearch.py -u https://target.com/admin/ -r -R 3 -w dict/special.txt这种“分层扫描”思路，比一次性开启无限递归要高效得多。
3.4 过滤噪声：-x、--exclude-status 与响应大小限制
python3 dirsearch.py -u https://target.com -x 403,404 -S-x用来排除指定状态码，最常用的就是把403和404过滤掉。-S是简单输出模式，让输出更简洁。
真正高级的过滤是为了对付“软404”。很多框架不存在的路径也会返回200，但响应大小基本固定。这类结果不排除，会把整个扫描结果污染掉。dirsearch提供了两个很实用的参数：
--min-response-size=500 --max-response-size=10000设置响应大小范围后，过小或过大的响应会被自动过滤，大部分软404会被挡在外面。另外还有个--exclude-texts参数，可以指定响应体里出现某些文本时视为无效，比如：
python3 dirsearch.py -u https://target.com --exclude-texts="Page Not Found,Resource Not Found"这个参数在处理开发框架自带的404页面时特别有效。
3.5 结果输出：--format 和 -o
扫描结果要及时落盘，别指望终端翻屏。dirsearch支持多种输出格式：
python3 dirsearch.py -u https://target.com -o result.json --format=json python3 dirsearch.py -u https://target.com -o result.txt --format=plain实际工作中，我一般同时输出JSON和纯文本两份。JSON用来后期脚本处理，纯文本用来快速人工翻阅。如果你有后续整理报告的需求，JSON格式会友好很多——每个结果都包含URL、状态码、响应大小、重定向地址等结构化字段，直接用脚本转成表格就行。
4. 字典爆破的秘密：为什么同一个工具，有人跑得深有人跑得浅
4.1 字典爆破的技术原理
目录扫描器在工作时做的事情其实很朴素：拿字典里的每一个路径拼接成URL，向目标发送HTTP请求，然后根据响应状态码和内容判断路径是否存在。
所以它本质上就是一次基于字典的“爆破”——不是去突破什么认证，而是爆破“路径”本身。
这里有个容易被忽略的点：状态码的判断逻辑。常见情况下，200表示路径存在，403表示存在但禁止访问，301/302表示路径存在且发生了重定向。404表示不存在。这四种状态码基本够用了。但真实的Web环境远比这个复杂，所以我会在下一章专门讲误判的问题。理解了这个原理你就会明白：扫描结果的天花板，完全取决于字典的质量。工具只是帮你发请求的，字典才决定了你能看到多大范围的“地图”。
4.2 常用字典资源与内置字典
dirsearch自带的字典按场景做了分类，在db/目录下：
| 字典文件 | 适用场景 |
|---|---|
dicc.txt | 通用中小型站点 |
directories.txt | 目录型路径 |
common.txt | 最常见路径，速度快 |
php.txt | PHP站点专用 |
backup.txt | 备份文件、临时文件 |
admin.txt | 后台路径 |
burp-parameter-names.txt | 参数名爆破 |
外部资源里，最出名的当属SecLists的Discovery/Web-Content目录，里面有大量分类精细的字典，比如raft-large-directories.txt、big.txt、Common-PHP-Filenames.txt等。我的建议是：拿SecLists作为扩充弹药库，日常还是以dirsearch自带字典为主，因为它是经过脱敏和去噪的，误报率控制得比较好。
4.3 如何构建自己的行业字典
与其满世界找“神级万能字典”，不如花一个小时，从目标本身提取路径规律。下面三个方法亲测有效。
第一，从站点的JS文件里收路径。打开开发工具，把站点的所有JS文件过一遍，API接口路径、管理端路径、静态资源路径都会暴露出来。把这些路径整理进字典，再对目录扫描做补充，效果远比通刷字典好。
第二，根据站点的技术栈生成定向路径。不同框架有固定的敏感文件习惯。比如ThinkPHP站点跑index.php、runtime/、.env；Spring Boot站点关注actuator/、swagger-ui.html、application.yml；WordPress站点关注wp-json/、xmlrpc.php。这些路径在通用字典里不一定有，但定向字典里命中率极高。
第三，按目标的信息做变体。如果你知道目标的子域名命名规律，开发者的文件名习惯（比如喜欢用拼音缩写、日期命名），完全可以把这些内容批量生成进字典。比如某个站点接口习惯用/api/v1/getUserInfo这种命名，那你就在字典里加入/api/、/api/v1/、/api/v2/这类前缀组合。
这里补充一个我常用的“笨办法”：用脚本把基础路径和后缀做笛卡尔积生成组合字典。比如一份基础路径清单有1000条，想生成同时包含php、bak、old、zip的变体，跑一小段Python就能完成。组合字典在第二轮补扫时很管用。
4.4 与Burp Suite爆破字典的联动
既然提到了Burp Suite，就把这块也展开说说。在真实测试中，dirsearch和Burp Suite经常是搭配使用的，配合好了能形成1+1>2的效果。
玩法一：把dirsearch的结果作为Burp的Target。扫描结束后，把确认存在的URL发送到Burp的Sitemap，后续针对这些路径做请求修改、重放、参数探测，比直接拿完整域名做测试要精准得多。
玩法二：把Burp抓包得到的路径反向整理成字典。用Burp代理浏览目标站点，收集所有真实请求的URL、路径、参数名，导出后整理成自定义字典，再用dirsearch去跑一遍相同路径的变体。这种方式特别适合针对未公开的接口——真实请求里透露出路径规律后，你可以推测出相邻、同规则的其他接口。
玩法三：用Burp Intruder做参数级爆破。dirsearch管的是路径发现，Intruder管的是参数和值。比如通过目录扫描发现了一个/api/query接口，接下来用Intruder加载burp-parameter-names.txt，逐个测试可能存在的参数名。这两者不是替代关系，而是先后关系。
这里插一句关于“burpsuite爆破字典”的说明——很多朋友问到底用哪份字典。其实Burp Intruder对字典格式没有特殊要求，一行一个payload即可。你可以把SecLists的相关字典直接加载，也可以把dirsearch的burp-parameter-names.txt拿来用。不需要去下什么“专用秘传字典”，理解了爆破目录、爆破参数各自的逻辑，选字典就不会迷茫了。
5. 扫描结果的鉴别逻辑：200不一定真存在，403不一定进不去
5.1 状态码判断的再梳理
很多新手拿到扫描结果，看到一堆200就激动，看到403就跳过。这种二元判断在真实环境里会漏掉大量有价值的信息。
先看一个我常用的状态码快速判断表：
| 状态码 | 通常含义 | 我们该怎么做 |
|---|---|---|
| 200 | 路径存在可访问 | 直接访问，确认内容 |
| 301/302 | 存在重定向 | 跟过去看目标地址，可能是后台或登录页 |
| 401/403 | 存在但无权访问 | 不要急着跳过，尝试改请求头、用不同方法访问 |
| 404 | 不存在（默认） | 排除 |
| 500 | 服务器错误 | 可能是存在但代码报错，值得看一眼 |
| 429 | 请求频率过高 | 说明扫太快了，停一停 |
特别想说一下403。很多人看到403就认为“进不去没价值”，但很多时候403只是服务器层面拦截了目录列表访问，不代表目录里的文件不能直接访问。比如/uploads/可能403，但/uploads/xxx.jpg是开放的。我一个朋友的项目里，目标站点/.svn/返回403，结果直接访问/.svn/wc.db却能下载，因为那条规则只拦了目录，没拦文件。对每个403，我推荐花十秒钟手动请求一次，验证后再划掉。
5.2 软404：最容易被忽视的假阳性
软404的本质是：所有不存在的路径，目标都会返回200，但响应内容是同一个“页面不存在”的提示页。如果扫描时不去过滤，你会看到几百条200，以为找到了大量敏感路径，点开全是同一个模板。
识别软404有几个常用办法：
- 看响应大小。如果一大批200结果的响应大小都接近，比如都在3000字节左右，这大概率是同一个软404页面；
- 看页面标题。把所有200结果的标题抓出来统计，如果高度重复，就是软404；
- 看关键词。比如经过统一处理的404提示页通常包含“Page Not Found”“数据不存在”这类固定文本。
dirsearch本身提供了一些规避机制，但最稳妥的还是将确认存在的路径手动请求一遍。我见过不少人拿了一堆软404的结果去写报告，被开发同事嘲笑了很久。目录扫描最忌讳的就是不加判断地粘贴结果。
5.3 找到敏感目录后的进一步验证
扫描只是第一步，确认结果才是体现功力的地方。我的验证流程是固定的：
- 直接请求看状态码和响应体，确认不是软404；
- 关注重定向目标，因为有些路径本身没内容，但会跳到后台登录页；
- 检查备份文件是否可下载，如果可下载，下载后注意不要随意解压执行里面的内容，避免触发安全告警；
- 记录证据，把URL、状态码、响应头、关键内容截个图，或者用curl保存响应到本地。
- 立即纳入报告，我会在测试过程中维护一个“有效资产”表格，每个确认结果填一行：URL、类型、风险描述、复现方式。
这套流程走完，才算真正把目录扫描结果的价值挖出来了。
6. 一次授权测试全流程复盘：从指纹识别到报告落地的细节
6.1 授权确认与范围界定
每次测试开始前，我最先做的不是开工具，而是确认两件事：目标范围是否书面授权，授权书里是否写明了域名/IP段和时间窗口。目录扫描会产生大量请求，如果没有提前跟目标确认清楚，很容易被认为是恶意扫描，测试性质就变味了。所以授权确认是所有后续步骤的前提，这一步省不得。
6.2 从指纹识别到扫描策略调整
假设这次测试的是一个中型企业门户网站。先用浏览器访问，看响应头里的Server、X-Powered-By，再查看页面源码里的框架特征，确认是Nginx+PHP，站点疑似ThinkPHP框架。
这时候扫描策略就很清晰了：
python3 dirsearch.py -u http://target.com -e php,json,yml -t 20 \ -w db/dicc.txt --format=json -o phase1.json第一轮用常规字典快速摸底，排除403/404。拿到结果后，对关注的路径做第二轮递归：
python3 dirsearch.py -u http://target.com/admin/ -r -R 2 \ -e php,bak,zip -t 15 -x 403,404同时在另一个方向，用专门沉淀的ThinkPHP路径清单补一轮。这套组合拳打下来，基本能把站点的主要暴露面摸全。
6.3 结果复核与报告编写
扫描阶段结束后，把JSON结果导入本地Excel/脚本做排序和过滤，重点是看200状态的条目，逐个手工验证。拿真实项目来说，最后筛出的有效条目通常只占原始结果的一成左右，包括：
/runtime/目录可列举，内含日志文件；/.env泄露数据库连接信息；/backup/portal_2023.sql数据库备份文件可下载；/admin/login.php后台地址确认存在，登录页面可正常访问。
每一条我都做了复现验证，截图保存，再写进报告。报告里不只是罗列URL，还写清“该路径目前可访问，建议限制访问权限/迁移备份文件/清理测试残留”，方便开发直接照着修。
6.4 扫描工具的边界与个人体会
dirsearch虽然好用，但它终究只是一个“发请求的机器”。工具替代不了人的判断，以下几点是我反复踩坑后总结的：
- 不要迷信默认字典。不同行业、不同框架的站点敏感路径差异很大，通用字典保障的是下限，自建字典才能抬高上限。
- 时刻关注测试目标的状态。扫描过程中偶尔用浏览器打开目标首页，确认站点响应正常。如果目标业务受到明显影响，立即调低线程或者暂停。
- 保留完整的请求日志。目录扫描是主动探测行为，留下日志既是专业的体现，也是为了后续复查方便。
- 记录下每一次扫描的时间、字典、参数。这样发现某个路径时，能知道它是哪轮扫描发现的、是什么上下文。没有上下文的结果，价值会大打折扣。
7. 防御视角：从攻击者的扫描，反推自己的加固清单
7.1 如果暴露面已经出来了，怎么快速止血
目录扫描这项技术本质上没有正邪之分，关键在于使用的人。防御方完全可以用同样的工具来审视自己的Web应用。定期用dirsearch对自家站点跑一轮，把扫描出来的敏感文件当成一次“预演”，就能在真实入侵发生前堵住漏洞。
止血操作可以按下面这个顺序来：
- 删除web目录下的备份包、测试脚本、临时文件——这是最高优先级，成本最低，治疗最彻底；
- 禁止web服务器解析/下载特定扩展名文件，比如
.sql、.bak、.env、.git等，在Nginx/Apache配置里直接deny掉； - 对后台路径增加访问控制，不能只靠“路径足够隐蔽”，IP白名单或内网访问是底线；
- 定期扫描并建立基线，每次版本发布后跑一次目录扫描，对比新增路径，及时发现残留文件。
7.2 关于敏感目录泄露的认知升级
很多开发同学觉得“文件放在深处就没人知道”，这种想法往往就是泄露的源头。目录扫描工具的存在恰恰证明了一件事：只要路径可被HTTP访问，就一定会被探测到。因此真正有效的方法，不是把敏感文件藏起来，而是让它根本无法通过web访问——比如放到web根目录之外，或者配置访问鉴权。实践中，凡是做了这两点的站点，即使目录扫描跑得再猛，敏感目录泄露的风险也能大幅降低。技术对抗的终极形态，永远是安全意识的对齐。
最后再分享一个我常用的收尾动作：每次跑完目录扫描，我会把确认的有效路径汇总整理成一份“敏感路径清单”，既作为交付报告的一部分，也会在下次测试相同目标时作为参考。这份清单会记录时间、URL、状态码、当时的修复建议。时间长了，它就成了一个非常有价值的历史对比库——哪个路径曾经泄露过、是否修干净了、是否又回潮了，一眼就能看出端倪。目录扫描的意义从来不止于发现，而是持续发现、持续收敛。这就是我一直坚持用它的原因。
