在一个授权渗透测试项目里我花了整整一个下午盯着终端滚屏结果只扫出来几个 403 和一堆 200 的静态资源。当时的第一反应是目标很干净直到客户无意间提到他们有一个内部系统曾经暴露过测试接口我才意识到问题不是目标干净而是我的目录扫描方式出了问题。这件事之后我认真把 dirsearch、字典爆破和敏感目录泄露挖掘这条链路重新梳理了一遍才发现大多数人对目录扫描的理解都停留在“跑一下字典等结果”的层面而真正的差距藏在字典的选择、结果的分辨和绕过策略上。这篇文章就围绕目录扫描这个主题把 dirsearch 的安装、参数调优、字典爆破原理、敏感目录识别和从扫描结果到实际利用的完整流程讲透。无论你是刚接触 Web 安全的新手还是已经写过几个扫描脚本的开发者只要想真正把目录扫描用出价值这篇文章都值得花点时间看完。1. 目录扫描到底在扫什么先搞清楚目标长什么样很多人把目录扫描当成一个跑完就有结果的黑盒工具拿过来就扫扫完就报告完全不理解自己在做什么。目录扫描的本质是通过 HTTP 请求的响应差异推测目标 Web 应用的文件结构和路由设计它不是一个自动化的漏洞利用工具而是一个信息收集工具。1.1 目录扫描的本质把黑盒变成灰盒当你面对一个目标站点时表面上你只看到首页、登录页最多加一个 robots.txt。但在服务端真实存在的可能还有 /backup/ 目录、/api/v1/internal/ 接口、/phpmyadmin/ 管理入口、/uploads/ 上传目录、.git 源码仓库。这些路径并不会主动暴露但它们是被动可探测的。目录扫描的做法就是构造大量候选路径逐个发送 HTTP 请求然后根据响应状态码和响应体内容判断这个路径是否存在。如果返回 200大概率路径存在返回 301/302说明路径存在且发生了重定向返回 403路径存在但禁止访问这本身就是一条有用的泄露信息如果返回 404基本可以判定路径不存在。这个过程本质上是在和服务端做问与答你问 /backup/服务器回答 403你就知道它存在于某个层面只是不让你直接访问。通过成百上千次问答你就能在脑海里拼凑出这个站点的目录结构画像把黑盒变成灰盒。1.2 哪些目标适合扫、哪些不适合目录扫描不是万能的它对目标的性格有要求。适合扫描的目标通常有几个特征使用传统 MVC 框架如 ThinkPHP、Laravel、Spring 等路由由后端控制器决定目录结构与路由存在映射关系服务器配置了静态文件目录如 Nginx 的 root 指向某个文件夹真实目录名直接暴露在 URL 中目标站点存在历史遗留文件如旧版本备份、测试脚本、临时上传目录不适合扫描的目标包括纯前端单页应用SPA路由全在前端后端只需一个入口文件字典扫不到有效路径全站动态参数型接口路径全部是 /api/getData?id1 这类不存在静态路径强 CDN 或 WAF 防护的高安全目标扫多了可能直接封你 IP。有意思的是403 响应往往比 200 更有价值。一个返回 403 的路径说明服务端针对这个路径做了访问控制背后通常藏着不想被公开访问的资源。我见过不少案例敏感目录 200 扫不到但 403 一抓一个准顺着 403 的目录名去猜备份文件位置往往能直接拿下配置源码。1.3 目录扫描和子域名枚举不是一回事新手最常见的混淆是把目录扫描和子域名枚举混在一起。前者探测的是同一个域名下的路径结构example.com/admin/login后者探测的是不同子域名的存在性admin.example.com。两者的字典完全不同前者是路径字典后者是主机名字典请求的 DNS 解析流程也完全不同。搞清楚这个区别你在选工具和写报告时才不会把两条线的结果混在一起。从方法论上看成熟的渗透流程通常是先做子域枚举扩大攻击面再对每个目标子域做目录扫描深化信息收集。2. dirsearch 的安装、参数调优与真实输出解读dirsearch 是目前使用率最高的目录扫描工具之一原因很简单速度快、字典丰富、输出格式友好、支持递归扫描。它用 Python 编写跨平台运行基本成了 Web 应用信息收集阶段的标准配置。但我见过太多人只是从网上抄了一段安装命令装完就扫很多关键参数从来没碰过。2.1 安装从源码开始绕开 apt 的坑很多人习惯用 sudo apt install dirsearch 安装但实际执行时经常遇到 unable to locate package dirsearch 的报错。这是因为 dirsearch 并不在 Ubuntu/Debian 的官方软件源里尤其在你没有更新软件源索引的时候系统根本找不到这个包。我推荐的做法是直接从 GitHub 拉源码运行git clone https://github.com/maurosoria/dirsearch.git cd dirsearch pip3 install -r requirements.txt python3 dirsearch.py --help这种方式的好处是始终使用最新版本字典文件也都在本地目录里后续自定义字典非常方便。如果你所在的环境拉取 GitHub 受限也可以找国内镜像源下载压缩包解压后同样运行。注意 Python 版本建议 3.7 以上老版本会报语法错误。安装完成后建议先跑一次 --help 看看版本信息和参数列表不同版本参数略有差异网上很多教程基于旧版照搬命令可能直接报错。2.2 常用参数不只看 -u还要看 -e -w -t很多人用 dirsearch 就只会写一行python3 dirsearch.py -u http://target.com这样能跑但只是默认配置远没发挥工具的能力。我每次扫描至少会加这样一组参数python3 dirsearch.py -u http://target.com -e php,html,bak,zip,txt -w /path/to/custom.dict -t 30 --random-agent --delay0.1 -o result.json逐个说明为什么这么配-e php,html,bak,zip,txt指定扩展名。dirsearch 会为每个候选路径追加这些扩展名逐个请求。默认只探路径加上扩展名后才能发现 index.php.bak 这类备份文件。扩展名列表要基于目标技术栈判断如果是 PHP 站点就重点放 php如果是 Java 站点就放 jsp,do,action。-w指定自定义字典。dirsearch 自带默认字典虽然能用但目标不同、字典不同命中率差异极大。关于字典的选择后面单独展开。-t 30线程数。默认线程偏低内网目标可以调到 50-100公网目标建议 20-30避免触发 WAF。--random-agent随机 User-Agent。很多站点的安全设备会拦截带有扫描器特征的 UA默认的 python-requests UA 很容易暴露。--delay0.1请求间隔控制速度的同时降低被封风险。-o result.json导出结果便于后期整理报告推荐 JSON 或 CSV 格式。另外两个被低估的参数是-r递归扫描和--full-url。递归扫描会在发现目录后自动进入该目录继续扫描比如发现 /admin/ 后继续扫 /admin/login、/admin/config 等这个功能非常有用但时间成本也高建议锁定目标目录再开启。2.3 输出解读怎么区分真目录和误报目录扫描结束后那一屏结果看着很爽但里面至少有三成是假的——不是工具错了而是 Web 应用的特性导致的。最常见的假阳性来源是自定义 404 页面。有些站点不管你请求什么不存在的路径都返回 200 状态码响应体是同一个页面不存在页面。dirsearch 只看状态码会误以为所有路径都存在。解决方法是开启--exclude-status404或者使用--exclude-text页面不存在参数让工具把符合某些特征的响应排除掉。更稳妥的做法是手动验证先请求一个随机生成的、几乎不可能存在的路径作为基线记下它的响应状态码和响应体长度然后对比扫描结果中每个 200/403 的响应是否和基线一致一致的就是误报。我自己的习惯是扫描完先导出结果再用脚本去重和过滤。比如一个常见操作是只保留 200、301、403 状态码响应体长度超过某个阈值的路径这些才是值得手工复验的候选。3. 字典爆破决定扫描上限的关键环节很多人忽略了一个事实扫描工具只是执行者字典才是决策者。工具负责把字典里的每个词发出去字典决定了你想到过哪些路径。如果字典里根本没有 backup.zip工具再快也扫不出来。目录扫描命中率的高低七成取决于字典的好坏三成取决于工具的使用。3.1 字典的本质尺寸与质量的权衡字典文件本质是一个候选路径集合。理论上字典越大覆盖的路径越多但请求量也越大时间成本和封 IP 风险同步上升。一个包含 1000 条记录的小字典可能几秒跑完但命中率有限一个包含 10 万条记录的超大字典可能要跑几个小时。关键是把字典用在正确的场景。通用场景下我通常分两层第一层用中小字典快速摸底控制在几千条到一两万条第二层用大字典对重点目录做深度扫描。这样既控制时间又保证覆盖面。3.2 字典分类通用型、程序类型、业务类型根据目标的技术栈和业务特征字典可以分为三类命中率差异非常明显。通用型字典包含最常见的路径和文件名如 admin、login、backup、upload、images、css、js、test、phpinfo.php、config.php.bak 等。这类字典适合前期快速摸底任何目标都可以跑一遍。dirsearch 自带的 db/dict.txt 就属于这一类网上常见的 top.txt 也属于这一类。程序类型字典针对特定开发框架或 CMS。比如 ThinkPHP 的路由有 /index.php?mHomecIndexaindex 这类参数型路径Laravel 的 /api 和 /telescope 是特殊路由WordPress 有 /wp-admin、/wp-content/uploads、/xmlrpc.phpGitLab 和 Jenkins 也有各自的管理路径。这类字典需要根据目标指纹提前准备比如你在响应头里的 X-Powered-By 或前端资源特征里发现了 WordPress就应该立刻切换到 WordPress 专项字典。业务类型字典根据目标业务定制的字典。比如一个电商站点可以加入 /admin/order/、/admin/user/export.php、/api/v1/coupon、/merchant/、/distributor/ 这类与业务逻辑强相关的路径一个论坛站点可以加入 /moderate/、/admincp/、/attachment/ 等。这类字典没有现成的需要你在日常测试中不断积累和总结。3.3 如何组合字典与规则提升命中率实际使用时可以把多个字典文件合并去重再按优先级排序。常用命令cat dict_general.txt dict_thinkphp.txt dict_business.txt | sort -u dict_merged.txtsort -u 去重很关键否则重复请求会浪费大量时间。排序建议把最可能命中的路径放前面这样即使扫描中途被封 IP至少先跑完了高价值记录。除了字典本身扩展名组合也是爆破的一部分。我常用的扩展名组合为 php、jsp、asp、aspx、html、bak、zip、tar.gz、sql、txt、xml、json、yaml、conf、log。注意一定包含bak和tar.gz这类备份文件在真实泄漏场景中占比极高很多站点把源码备份放在了 Web 目录下命名不规范就会被扫出来。3.4 爆破提速与可观测性目录扫描的提速有两个方向一个是提高请求并发数也就是把-t调大但并发过大会影响响应时间的准确性另一个是减少无效请求比如先通过-e只测试目标语言对应的扩展名而不是把十几个扩展名全部跑一遍。可观测性也很重要。dirsearch 的滚动日志里有很多信息建议在扫描过程中隔一段时间看一眼统计信息如果长时间没有新的有效响应说明当前字典快跑空了可以考虑换字典或者调整策略。我还会用--minimal-response-length过滤掉过短的响应减少噪音让结果更聚焦。4. 敏感目录泄露挖掘的实战思路从扫到到利用扫出目录只是第一步真正体现一个安全研究者功力的是能从一堆路径中快速识别出哪些是敏感泄露点并且知道如何利用它们。如果你只是把所有路径贴进报告那和扫描器没什么区别。4.1 先想清楚敏感目录有哪些常见形态敏感目录泄露通常有几种典型的形态版本控制目录泄露/.git/、/.svn/、/.hg/ 这类目录暴露在 Web 根目录可以直接通过 HTTP 访问。这是最严重的一类泄露意味着整个源码库可能被下载。备份文件泄露/www.zip、/site.tar.gz、/backup.sql、/config.php.bak、/web.rar。这类文件通常体积较大命名有规律一旦下载就可以离线分析。管理后台入口泄露/admin/、/manager/、/console/、/phpmyadmin/、/adminer.php、/actuatorSpring Boot Actuator。敏感接口泄露/api/internal/、/api/v1/debug、/swagger-ui.html、/v2/api-docsAPI 文档。API 文档泄露等于把接口列表直接送给你。临时文件与测试文件泄露/test.php、/info.php、/demo/、/phpinfo.php、/upload/test.txt。这类文件经常暴露环境信息或直接给出一个可利用的上传入口。4.2 识别敏感泄露点的排查清单扫描结束后我会把所有结果按优先级排序然后逐项验证。我给自己梳理了一个清单分享出来供参考第一个必查项是/.git/。如果存在且没有被禁止访问直接用工具把源码拉下来。具体操作是先用 curl 请求 /.git/HEAD看是否返回ref: refs/heads/master如果是说明 .git 目录可读就可以利用 GitHack 这类工具还原当前版本的核心代码。还原后你就能拿到数据库配置、密钥、接口逻辑等大量敏感信息。第二个必查项是备份文件。看到 .zip、.tar.gz、.bak、.sql 结尾的高响应长度文件先下载再说。下载后本地解压重点关注配置文件.env、config.php、application.properties和包含关键词 password、secret、key、token 的文件。第三个必查项是管理后台。扫描结果里出现 admin、login、console 这类路径时先确认目标技术栈再针对性尝试弱口令或寻找已知漏洞。千万不要在授权范围外做任何暴力破解尝试但仅仅确认管理后台入口的存在就是一条合格的信息收集产出。第四个必查项是API 文档。Spring Boot 项目的 /v2/api-docs 或 /swagger-ui.html以及各种 /api-doc、/redoc 路径一旦探到优先导出接口文档。接口文档里常常包含未鉴权的调试接口这类接口可能直接泄露用户数据或允许调用敏感操作。4.3 从扫描结果到验证利用的详细过程扫描只是发现线索验证才是确认漏洞。举一个我处理过的具体案例客户站点目录扫描发现 /backup/ 返回 200但页面内容为空。我没有直接把这个结果当误报丢弃而是继续请求 /backup/../robots.txt确认 Web 服务器存在路径穿越配置然后对 /backup/ 做递归扫描结果扫到 /backup/db_backup_2023.sql。下载后打开发现 3 万多条用户记录包括用户名、手机号、加盐的密码 Hash。最终这个案例归结为备份文件泄露 敏感信息泄露修复方案是禁止 Web 目录存放任何备份文件。这个案例里的关键动作是对可疑目录不要停在一次验证要递归扫描。目录扫描是一个不断深入的过程第一次扫出来的结果是你第二次扫描的起点。再补充一个技巧响应长度异常的路径值得特别关注。比如同样返回 200 的路径大多数响应体大小在 1KB 以下唯独某个路径返回了 50MB 的文件那大概率就是备份包或日志文件。我习惯用脚本统计所有有效响应的 Content-Length做离群值分析比人眼一条条看快得多。4.4 扫描结果的报告输出拿到验证后的敏感目录和文件报告里应该包含目标 URL、请求方法、响应状态码、响应体特征、复现的 curl 命令、影响评估。curl 命令的价值在于方便对方复现一条可执行的命令比十行描述更有说服力。输出格式我通常用 Markdown 表格按严重程度排序。5. 绕过策略与常见防护对抗扫描器失效时的对策任何工具都有被针对的可能目录扫描最大的天敌是 Web 应用防火墙WAF和反爬机制。当你发现扫描速度骤降、大量请求返回 403、或者所有路径无论是否存在都返回同一个页面时说明目标已经识别并拦截了你的扫描行为。5.1 观察目标变脸判断是否被拦截扫描过程中要随时关注响应变化。一个明显的信号是在某个时间点之后所有请求都返回 403而且响应头里出现了 WAF 特征如 X-Cache、Server: xxx-WAF说明你的 IP 已经被临时封禁或者触发拦截规则。另一个隐蔽的信号是响应体模板固定。无论请求什么路径都返回同一个 404 或 200 页面说明目标可能配置了全局拦截规则对扫描器类 User-Agent 或高频请求统一返回假页面。5.2 调整请求身份User-Agent、延迟和代理最基础的对抗措施是伪装请求身份。--random-agent参数可以随机生成浏览器 UA大幅降低被识别为扫描器的概率。如果目标站点要求登录才能访问可以先用浏览器登录获取 Cookie然后通过-H Cookie: sessionxxx参数让 dirsearch 携带会话状态扫描这样请求更像真实用户行为。延迟调整也很关键。把--delay设置到 0.5 到 1 秒之间虽然扫描时间变长但触发拦截的概率大幅下降。内网环境可以忽略延迟公网渗透测试强烈建议加延迟。5.3 路径编码绕过当目标过滤了特定路径有些目标的防护规则会拦截包含 admin、config、backup 等关键词的请求。这种情况下可以尝试 URL 编码绕过把 /admin/ 写成 /%61dmin/a 的 URL 编码是 %61使用路径混淆写法/admin/./ 、/admin/../admin/在路径末尾加分号/admin/;.js双写关键字//admadminin/这些技巧的底层原理是WAF 规则和 Web 服务器对 URL 的解析方式存在差异WAF 可能只做了简单的字符串匹配而 Web 服务器在解析时会做合并和规范化。如果你不确定目标是否支持这些写法先手动 curl 试探一下再开扫。5.4 分布式扫描与并发控制面对防护严密的公网目标可以通过代理池或换 IP 来分散请求频率。但我不建议在未授权测试中大量使用代理池因为来源 IP 分散可能触发更高级的关联检测。更稳妥的方式是控制单 IP 的请求速率比如把线程数降到 5-10配合 0.3-0.5 秒的延迟把扫描时间拉长到几小时完成让行为更接近人工浏览。6. 一次完整扫描流程实战从信息收集到报告输出前面把原理、工具、字典、思路都讲了一遍最后用一个完整的实战流程把这些内容串起来。假设目标是一个授权范围内的 PHP 站点。6.1 前期基础信息收集扫描前先花五分钟做信息收集能极大提高后续扫描效率。先用浏览器访问目标首页按 F12 看响应头和前端源码。重点看 X-Powered-By、Set-Cookie、generator meta 标签这些常常直接暴露开发语言和框架再看 robots.txt 和 sitemap.xml里面可能直接列出部分目录。同时用 curl 请求一个不存在的路径记录基线响应特征为后续识别误报做准备。curl -I http://target.com/ curl -s http://target.com/robots.txt curl -s -o /dev/null -w %{http_code} %{size_download}\n http://target.com/nonexist_whatever_12345.php基线响应记录下来后面比对就方便了。6.2 分层执行目录扫描第一层用通用中小字典快速摸底python3 dirsearch.py -u http://target.com -e php,html,txt,bak,zip --random-agent -t 20 --delay0.1 -o phase1.json扫描结束后先处理结果排除掉和基线响应特征一致的误报。假设扫出了 /admin/、/uploads/、/test/、/.git/ 这几个关键路径。第二层针对重点路径做递归扫描和专项字典扫描。对 /admin/ 用管理员后台专项字典对 /uploads/ 尝试列出目录或找上传文件对 /.git/ 做源码泄露利用。同时用大字典对整站做一次补充扫描专门找备份文件python3 dirsearch.py -u http://target.com/admin/ -w dict_admin.txt -e php,html,bak -r -t 30 --delay0.2 python3 dirsearch.py -u http://target.com/uploads/ -w dict_upload.txt -e php,jpg,png,zip,txt --random-agent6.3 结果验证与利用每个高价值路径都要人工验证不能只看扫描器输出。验证 .git 泄露用 curl 请求 HEAD验证备份文件直接下载验证后台入口用浏览器访问。验证过程中严格记录证据curl -s http://target.com/.git/HEAD curl -s -o db_backup.sql http://target.com/backup/db_backup_2024.sql如果发现源码泄露拉下来后优先看配置文件和数据库连接信息。如果发现备份文件解压后搜索关键词。整个过程中的每一个新发现都可能成为下一轮扫描的输入。最终把验证过的敏感目录、泄露文件、后台入口整理成报告按风险等级排序。一个典型的结论是站点存在 .git 源码泄露风险导致数据库配置、业务逻辑源码可被完全获取存在备份文件泄露包含历史数据库导出数据后台入口未做访问控制。6.4 关于报告与修复建议报告不只是罗列问题还要给出可落地的修复建议。目录扫描类问题的常见修复方向包括禁止 Web 根目录存放 .git、.svn 等版本控制目录敏感备份文件一律移出 Web 可访问路径后台入口限制来源 IP 或增加二次认证对 404 响应做统一处理避免泄露服务器类型信息。修复后建议再扫一遍确认问题是否闭环。目录扫描这个技能看似简单真正用好了是一条非常关键的信息收集能力。它不直接产出漏洞但几乎所有高质量渗透测试的开始都伴随着可靠的信息收集。字典要不断积累扫描结果要会分辨拿到线索要会深挖这些能力不是看一篇教程就能掌握的而是在一次次实战中磨出来的。我个人体会最深的一点是不要迷信任何工具或字典把每次扫描都当成一次和目标的对话仔细听它的回应往往会有意外收获。