做授权测试的时候我拿到一个目标域名后的第一件事往往不是急着找漏洞而是先跑一遍目录扫描。原因很简单你直接打首页可能什么都看不出来但后台路径、备份压缩包、.git目录、接口文档这些敏感目录往往会悄无声息地暴露在路径里而这些就是后续测试的突破口。今天就把我在实际测试里最常用的 dirsearch 目录扫描思路、字典爆破技巧、以及怎么从结果里判断哪些敏感目录值得跟进一次性梳理清楚。写这篇东西的初衷是最近好几个读者问我同一个问题为什么我装了 dirsearch 一用就报unable to locate package dirsearch为什么我扫了一堆路径但不知道怎么分析说白了目录扫描这个动作本身不复杂但背后的字典选择、参数调优、结果研判才是真正拉开差距的地方。这篇就适合刚入门的渗透测试新手、做企业安全巡检的运维同学还有那些想搞清楚“扫描器到底扫了些什么”的开发者。1. 目录扫描的底层逻辑与信息收集价值1.1 目录扫描到底在做什么很多人第一次用 dirsearch看到终端里快速滚动的进度条会觉得这工具挺玄乎。其实拆到最底层目录扫描的原理非常朴素对目标域名/路径发一批 HTTP 请求每个请求探测一个可能的目录或文件名然后根据响应状态码判断这个路径是否存在。用一个生活化的类比来说这就像你在一栋办公楼里挨个房间敲门门开了说明有人没响应就换下一间。dirsearch 干的也是这件事只不过把“敲门”变成了 HTTP GET 请求把“门牌号”变成了/admin、/backup、/.git/HEAD这类常见路径。状态码就是敲门后得到的回应200路径存在内容可访问——最直接的成果。301/302路径存在但发生了跳转可能是登录页、也可能是 CDN 的强制 HTTPS 跳转。403路径存在但被拒绝访问。很多人一看到 403 就跳过这是非常可惜的——403 恰恰说明服务端识别了这个路径只是你没有权限这说明它真实存在于目标系统里。404路径不存在正常忽略。之所以要用工具而不是手工一个个试是因为目录扫描本质上是海量请求的重复劳动人力做不了而脚本可以在几分钟内发出数千个请求。dirsearch 之所以是这个领域的常青树就是因为它把“发请求 判断状态码 输出结果”这套流程封装得足够好用而且字典替换非常灵活。1.2 与漏洞扫描器、爬虫的本质差异这里我想专门区分一个容易混淆的概念目录扫描 ≠ 漏洞扫描 ≠ 爬虫。爬虫的工作方式是顺着页面里的超链接一个页面跳到另一个页面把你能看见的公开资源抓下来。漏洞扫描器则是先爬取目标再对每个 URL 做参数注入、XSS、SQL 注入等漏洞探测。而目录扫描器做的是另一回事——它不关心页面里有什么链接它只关心目标系统里有没有那些不主动出现在页面上、但确实存在的路径。这就是目录扫描的核心价值之一专门去找那些开发者不想让你发现的东西。比如测试环境的登录后台/test-admin/忘记从服务器删除的备份文件bak.zip版本管理工具泄露的源码目录.git/接口调试文档/api/swagger-ui.html日志文件/log/info.log这些路径有一个共同特征正常用户通过页面导航永远点不到它们但它们就安静地躺在服务器的目录结构里。如果被攻击者扫到轻则泄露信息重则直接拿到源码或后台权限。1.3 敏感目录泄露为什么值得重点关注在前几年的一次授权测试里我通过目录扫描发现目标站点上挂着一个backup_2023.zip。下载下来解压后发现是整套站点的源码加数据库备份文件里面甚至包含管理员账号的加密密码和连接字符串。后续的事情就变得很简单离线破解、修改密码、进后台、拿 webshell。整个过程里我没有利用任何 0day就靠这一个被遗忘的备份文件。类似的故事在真实世界里反复上演。敏感目录泄露之所以危险是因为它往往不是单一漏洞而是一把打开后续攻击链的钥匙.git目录泄露 → 用工具还原源码 → 做白盒审计 → 找到代码级漏洞。后台路径泄露 → 暴力破解或弱口令测试 → 拿到管理权限。API 文档泄露 → 了解接口结构和参数 → 构造恶意请求。日志文件泄露 → 找到真实用户信息或调试信息 → 进一步钓鱼或撞库。这也是为什么在安全测试中目录扫描和信息收集永远排在漏洞挖掘前面——你连系统有哪些门都不知道谈何攻破它2. 工具选型与环境安装2.1 主流目录扫描工具横向对比关于目录扫描工具市面上的选择其实不少除了 dirsearch 之外御剑、ffuf、Burp Suite 的 Intruder 也都经常被提到。用之前得先搞清楚每个工具的定位否则容易在错误场景里浪费时间。我画了一张对比表方便你按需选择工具开发语言运行平台核心优势主要局限dirsearchPythonLinux/macOS/Windows字典灵活、支持递归、社区活跃、扩展名配置方便对超大字典的吞吐量不如 ffuf御剑目录扫描未知闭源WindowsGUI 操作直观、集成大字典、上手快不支持深度定制、代理配置弱、跨平台性差ffufGo跨平台速度极快、模糊测试理念、可做参数/子域/Vhost 爆破参数较多、学习曲线略陡Burp Suite IntruderJava跨平台与抓包爆破联动、可视化好、支持复杂爆破场景社区版速度受限、配置较重如果你只打算留一个工具我会毫不犹豫留 dirsearch。原因有三开源透明、字典体系完善、命令行环境适配好。御剑更多是作为 Windows 环境下的轻量补充尤其是想要现成大字典又没有 Python 环境的时候直接解压就能用。ffuf 则更适合进阶玩家做更广的模糊测试这点后面细说。2.2 安装 dirsearch 的三种方式与避坑直接说大家问得最多的unable to locate package dirsearch。这个报错我在 Debian/Ubuntu 系上经常看到很多人以为是自己软件源的问题拼命apt update结果发现还是装不上。原因很直接Debian 的官方软件源默认不收录 dirsearch所以apt install dirsearch自然找不到包。网上有些教程会让你添加 Kali 的源再装我不太建议这么干——在非 Kali 系统上混用 Kali 源容易把整个系统的依赖关系弄乱得不偿失。正确的安装方式有三种按推荐程度排序方式一pip 安装最快pip3 install dirsearch dirsearch -u http://example.com注意如果你用的是 macOS 或 Linux 的 Python3 环境可能遇到 externally-managed-environment 的权限限制建议先建虚拟环境python3 -m venv ~/dirsearch-env source ~/dirsearch-env/bin/activate pip install dirsearch方式二源码安装最稳妥从 GitHub 拉取官方仓库直接运行入口文件。这种方式的好处是你可以随时git pull拉最新版而且不依赖 PyPI 的更新节奏git clone https://github.com/maurosoria/dirsearch.git cd dirsearch python3 dirsearch.py -u http://example.com方式三Kali 系统直接安装如果你用的是 Kali Linux那就简单了Kali 的软件源默认收录了 dirsearchsudo apt update sudo apt install dirsearch装完之后验证一下能正常输出版本号就算成功dirsearch --version提醒在真实测试前先在本地起一个测试环境跑一遍命令确认网络、代理、字典路径都没问题。否则到了授权目标前才现找问题会很被动。3. dirsearch 核心功能与参数调优3.1 第一次扫描必须掌握的七个参数dirsearch 的参数非常多但绝大多数场景下你真正要记的只有七个。只要把这几个吃透就能覆盖日常 90% 的需求。我结合一个实际扫描命令来拆解dirsearch -u https://target.com -e php,html,bak -t 20 --random-agent -x 404 -o result.txt拆开来看-u指定目标 URL。注意带上协议头http://和https://的扫描结果可能会有差异。-e指定要追加探测的扩展名。因为同一个路径可能是.php也可能是.html或.bak。我这里试了 php、html、bak 三个实际环境里应根据目标所用语言调整。-t并发线程数。默认是 25实际测试中 20 到 30 之间比较适中。太大容易触发目标的风控太小扫描速度太慢。--random-agent使用随机 User-Agent。有些 WAF 会拦截默认的扫描器 UA这个参数能降低被拦概率。-x排除指定的状态码。-x 404表示不输出 404 的结果让结果更干净。想看 403 就不要把 403 排掉我一般只排 404。-o把结果保存到文件。格式可以是 txt 或 json方便后续分析。如果你要扫的站点是纯静态站可以把-e参数整个去掉只扫目录不扫文件如果是 PHP 开发的站点-e php是必加项否则admin.php这类文件就会被漏掉。3.2 递归扫描与深度控制目录扫描有个很常见的误区扫完一层目录就万事大吉。实际上很多敏感文件藏在二级甚至三级目录下比如/admin/backup/sql/。这时候就要用到递归扫描。我的习惯是这样的dirsearch -u https://target.com -e php -r -R 2-r开启递归扫描发现了有效目录后自动进入该目录继续向下扫。-R 2限制递归深度为 2 层。这个限制非常重要无限递归既浪费时间也可能让目标服务器不堪重负。但递归扫描有它的代价请求量会呈指数级增长。比如第一层扫出 50 个有效目录每个目录里又有几十个子目录整体请求量会非常大。所以我的建议是先用短字典快速扫第一层确认目标确实存在多级目录结构后再开启递归深度为 2 到 3 的扫描。上来就-r加-R 5大概率会把自己先耗死。3.3 字典配置的核心技巧dirsearch 默认自带了一个字典文件db/dicc.txt但这个字典覆盖度比较基础。实战中我更常用的是官方仓库里另一个更完整的字典db/directory-list-2.3-medium.txt配合-w参数指定dirsearch -u https://target.com -w /path/to/dictionary.txt字典的选择直接影响爆破效果。判断一份字典合不合格我通常看三点是否包含常见的管理后台路径admin、manager、system、console 等。是否包含备份文件命名规律xxx.zip、xxx.tar.gz、xxx.sql、xxx.bak等。是否包含开发相关敏感路径.git、.svn、WEB-INF、api、swagger等。如果你懒于自己整理可以在三个地方找字典资源dirsearch 官方仓库的db目录、SecLists 项目中的Discovery/Web-Content目录、以及网上开源的字典合集。但记住一条经验字典越大漏报越少但误报和时间开销也越大。相比追求大而全我会更看重字典是否贴合目标技术栈。4. 字典爆破进阶思路4.1 从目标特征推断字典内容脱离目标谈字典没有意义。同样是目录扫描扫一个 ThinkPHP 开发的站点和一个 Java Spring Boot 开发的站点重点字典完全是两回事ThinkPHP 站点优先关注/application/、/runtime/、/public/、/index.php等框架路径和.php扩展名的敏感文件。Spring Boot 站点优先关注/actuator/、/swagger-ui.html、/api/、/WEB-INF/classes/等端点路径。如果你知道目标用的是某个 CMSWordPress、Discuz、DedecMS那直接搜对应 CMS 的专属路径字典比通用字典效率高得多。这些信息从哪里来最简单的办法是看首页的响应头、页面版权信息、静态资源路径后缀。比如发现页面底部有Powered by ThinkPHP那字典就往 PHP 方向倾斜。先做指纹识别再做目录爆破这是信息收集的标准节奏能避免拿通用字典乱撞。4.2 自建字典的命名技巧与实战场景自建字典看起来简单实际很多人建出来的字典命中率极低因为他们只是把单词堆在一起。这里分享几个我在实战中总结的命名思路备份文件的常见命名规律。国内很多开发者的备份习惯是把站点压缩成站点名.zip、站点名_日期.zip、www.zip、web.zip、backup.zip然后在路径后追加这些常用名去探测。比如www.zip web.zip wwwroot.zip site.zip backup_2024.zip 20240101.zip后台路径的变体规律。admin几乎是标配但真实场景里很多人为了安全会改成houtai、manage、gl、system_admin这类变体。我的字典里会把这些中文拼音、缩写全部列进去。还有一种思路是从公司名称或部门名称推断比如目标公司叫“蓝海科技”那后台路径可能是lhkji_admin或lanhai。开发文件的后缀组合。同一个路径加不同扩展名去探测时顺序很重要。.php、.jsp、.asp、.aspx是语言文件.bak、.txt、.conf、.sql是备份/配置文件.json、.xml是数据文件。这些扩展名可以交叉组合比如config.php.bak——很多开发者在备份配置文件时直接在原文件名后追加.bak这种路径 dirsearch 配合多个扩展名能覆盖到。自建字典不需要一次性搞得很全我通常是随时发现、随时补充。每测一个新的目标就把新发现的敏感路径加进字典长期下来这本字典会变得非常贴合国内互联网站点的特征。4.3 结合 Burp Suite 做二次精细化爆破dirsearch 适合大范围路径发现但遇到“路径知道了一部分、但不知道完整文件名”的场景我更喜欢把它扫出来的初始结果交给 Burp Suite 做二次爆破。举一个典型的例子你需要猜后台管理认证接口但完全不知道参数名。先用 dirsearch 扫出目标存在一个/api/目录然后启动 Burp Suite把请求包发送到 Intruder对接口路径或参数名设置 payload 位置用burpsuite爆破字典做穷举。具体操作上抓取一个正常请求找到要爆破的位置并标记。选择爆破类型 Sniper单字典或 Cluster bomb多字典组合。加载字典例如参数名字典username、user、account、uname等配合关键字字典login、auth、check、validate等。开始攻击后通过长度和状态码筛选结果——响应长度明显偏离基线的一般就是有效接口。这一套配合下来等于把目录扫描从“发现路径”升级为“发现功能点”能帮你在写渗透测试报告时提供更扎实的证据链。提醒Privilege 是有限的爆破次数同样会触发 WAF。Burp Intruder 请求间隔建议调成 100~500 毫秒别把目标打成熔断状态。5. 扫描结果分析与敏感目录深入研判5.1 结果里哪些路径值得优先跟进dirsearch 扫完之后通常会给你一大堆结果新手最容易犯的错误就是看到200就兴奋然后一股脑全点开。更务实的做法是按优先级排序把精力放在最容易出成果的路径上。我在实际测试里的研判顺序大概是这样的第一梯队是版本控制目录.git/、.svn/、.hg/。一旦确认目标存在.git目录且可以访问就值得用工具把历史提交记录拉下来看看。很多项目早期版本里硬编码了数据库密码、API Key就算当前版本清理掉历史提交里也可能留着。第二梯队是备份与压缩包.zip、.tar.gz、.sql、.bak、/backup/、/temp/这类路径。备份文件的价值不用多说一个未授权下载的数据库备份几乎等于直接沦陷。第三梯队是管理后台与接口文档/admin/、/manager/、/swagger-ui.html、/api-docs/。后台路径意味着你可以尝试弱口令接口文档则暴露了系统的 API 设计是后续 API 安全测试的靶子。第四梯队是配置文件与日志config.php、application.yml、web.config、info.php、phpinfo.php、/logs/。这些文件通常包含敏感配置信息泄露后对攻击者来说就是保送消息。5.2 403 和 302 的隐藏信息挖掘我在前面提过不要轻易忽略 403 和 302这里展开细说。拿到 403 响应时第一反应不该是“这个进不去”而应该是“这里可能存在一个服务端有感知的路径”。403 的含义是服务器知道你要访问这个地址但没有放行。这背后有几种可能一是目录存在但权限配置错误二是目录由业务系统做了访问控制三是 WAF 拦截了扫描特征。判断方法是换一个浏览器 UA使用正常浏览器的完整请求头去手动访问这个路径看看响应是否变化。如果还是 403再试试路径穿越和大小写绕过如果变成 200说明只是 WAF 拦了扫描流量路径本身是开放的。302 则需要关注跳转目标。dirsearch 默认会把 301/302 标注为重定向你可以在浏览器里打开看看它跳到哪里。比如/admin跳到/admin/login.php那说明后台管理系统是存在的只是需要登录如果跳到某个第三方域名那就可能是 SSO 单点登录入口后续可以围绕认证逻辑做测试。5.3 从目录扫描结果到完整泄露链单一的敏感目录价值有限但它往往是整个泄露链的起点。我遇到过很多次最初的“.git 泄露”最终演变成“源码审计 → 发现注入点 → 拿下整个后台”的完整攻击链。所以扫描完成不代表工作结束反而是真正开始。一个比较落地的推进路线是这样的拿到正确的敏感路径后先抓取该路径的响应头确认中间件类型和版本——这决定了后续能否直接利用已知漏洞。然后是抓取页面内容分析是否存在硬编码的注释信息、测试账号、内网 IP 地址。如果是接口文档就找出认证机制是 Token 还是 Session看有没有未授权访问的接口。一步一步把信息拼起来很多突破口就是这么出来的。好的情况是拿到.git目录这时可以考虑用 GitHack 一类的工具把源码拉取下来进行代码审计。不过这里涉及的具体利用过程就不再展开了原则还是一样一切测试必须在授权范围内进行。6. 常见问题排查与避坑实测6.1 高频问题速查表问题触发原因解决建议unable to locate package dirsearch默认 apt 源无此包改用 pip 或 git clone 方式安装不要乱加源扫得太慢 / 线程耗尽线程数过低适当提升-t到 30~50同时配合--timeout缩短请求等待误报太多全是 200服务器对所有未知路径返回 200打开几个 200 结果看内容确认是自定义 404 页还是真实路径大量 403 拦截WAF 识别了扫描器特征加--random-agent绕不过就先暂停降低请求频率扫到一半卡住不动TCP 连接被目标丢弃加--timeout10和--retries2适当降低线程字典命中率极低通用字典与目标技术栈不匹配先做指纹识别再换针对性字典结果文件和屏显不一致结果文件默认保存过滤后的内容用-o result.txt时确认-x参数不会把你想保留的内容过滤掉6.2 我在实际测试里踩过的几个坑第一是开线程太猛导致源 IP 被封。早年间我第一次用 dirsearch 的时候为了追求速度直接把线程调到 100 去跑一个生产站点结果跑着跑着发现目标把所有请求都返回 403。原因就是目标安全设备检测到短时间内的超高频率请求直接把源 IP 封了。后来我收敛到 20 线程扫了快半个小时才缓过来。从那以后我给自己定了一个规矩默认 20 线程起步确认目标防护策略后再说宁愿慢一点也不要因为扫描把目标环境和后续测试搞砸。第二个坑是过度信任扫描结果。有时候脚本返回 200我到浏览器里一打开发现就是目标服务器自定义的 404 页面。对这种站点直接用路由器访问所有不存在的路径都会返回 200所以扫描结果里全是“存在”的路径。判断方法很简单随机挑几个不存在的古怪路径比如/asdkjhq123去访问如果返回也是 200说明目标把 404 统一处理成了 200这时候就得以内容匹配为准而不是状态码。第三个坑是把所有 p3f88 都当成有效路径去深入测试。目录扫描本来就是猜测行为如果目标用的是纯前端单页应用SPA很多路径实际上只是前端路由的一部分并不对应真实存在的后端目录结构。遇到这种站点我会换个思路直接看前端打包出来的 JS 文件从里面找真实的接口和路径比硬爆破有效得多。6.3 测试节奏与边界意识目录扫描是个容易让人上头的事情——看到状态码刷屏就想一直跑下去但冷静下来想想扫描只是手段不是目标。合理的一轮目录爆破流程应该是先指纹识别确定目标语言和框架再快速轻量扫描第一层分析结果后制定有针对性的第二次扫描方案然后根据结果决定是否深入测试。整个过程要有计划有热身有收尾。那种一上来就挂个超大字典无限递归跑一整天的操作既低效又容易出问题。如果你是在做授权渗透测试还涉及个节奏问题——什么时候需要暂停扫描去深入验证一个发现的路径我的经验是在目录扫描阶段发现一个200且指向后台登录接口的路径时立刻暂停全部扫描先用两分钟人工确认是不是真的后台入口。是的话接下来就围绕这个入口去做登录逻辑测试效果远好于把整个字典跑完再回头。信息收集本来就是动态调整的过程而不是一条流水线走到底。边界问题更要时刻谨记所有的目录扫描、字典爆破、敏感目录测试必须建立在获得测试授权的前提上。扫描器是无差别发请求的一旦目标安全设备记录到你的探测行为责任边界就很清楚——你只能对授权列表内的目标做测试。这一点不只是职业操守也是保护自己最基础的红线。如果你也是刚开始接触这一块我的建议是别急着去跑各种大字典。先把 dirsearch 在本地环境跑熟把结果里不同状态码的含义吃透再拿自己搭建的靶场练手。等真正能分清哪些路径是误报、哪些路径值得深挖再进入实际授权测试场景会从容很多。目录扫描这活儿看起来简单真正拉开差距的地方全在细节里多跑几轮多翻几次真实目标体感就出来了。