简介《dirsearch-master》是一份基于 Python3 开发的 Web 目录扫描工具源码包面向 CTF 参赛者、渗透测试人员及安全学习者。整套资源共 88 个文件压缩后约 194KB以 64 个 Python 脚本为主体另有 7 份 Markdown 说明文档及 txt 字典、yml 配置等辅助文件便于直接运行、按需定制和快速部署。工具通过枚举服务器上的隐藏目录与文件来探测敏感路径支持多线程、自定义词典并可导出 CSV、HTML、JSON 等格式结果在 CTF 中常用于发现包含口令、密钥或 flag 的目录信息。包内除主程序 dirsearch.py 外还提供 lib、tests、db、reports 等模块目录结构清晰既能开箱即用地完成扫描也方便读者深入理解扫描原理并在此基础上做二次开发。目前已有 2011 人学习下载适合需要在渗透测试或解题赛中高效定位隐藏资源的中高级安全爱好者使用。1. 为什么值得打开这个压缩包做站点测试时最耗时间的不是抓包而是把目标系统里那些看不到的目录一个个翻出来。靠爬虫只能拿到页面里存在链接的地方真正的管理入口、备份文件、老旧接口往往藏在 robots.txt 之外有的连站内都不引用。第一次手动把常见路径猜了上百个之后我就意识到这类工作必须交给专门的扫描器来做。dirsearch-master.zip正是干这个的源码包解压后就是一个完整的 Web 目录扫描工具用 Python 写成跑起来只需要一条命令。它解决的问题很具体——在授权测试范围内快速枚举目标站点存在哪些路径、文件、备份、后台入口供后续人工验证。适合的读者也很清晰做安全测试的工程师、被要求梳理资产目录的运维以及想搞懂字典扫描原理的开发者。我先把结论放在前面这个工具不值得你反复造轮子但值得你花半小时把参数真正吃透剩下的交给它去跑。2. 从 zip 到跑通部署与最小扫描命令拿到dirsearch-master.zip之后第一步不是找文档而是确认环境、解压、跑通一条最小命令。这步顺了后面的参数调整才有着落。2.1 解压与运行环境确认这个压缩包解压后会得到一个包含完整项目文件的目录入口脚本是dirsearch.py。它依赖 Python 的requests等库绝大多数系统装上 Python 3 后可以直接运行缺什么由报错告诉你不需要预装一堆东西。# 解压到当前目录 unzip dirsearch-master.zip # 进入项目目录目录名以实际解压结果为准 cd dirsearch-master # 确认 Python 3 可用 python3 --version # 检查入口脚本是否能正常响应 python3 dirsearch.py --version这里python3和python的区别值得留意在 Linux/macOS 上python3通常是标准命令在 Windows 上如果你只装了官方 Python输入python即可。如果你的机器上同时有 Python 2 和 3务必用python3否则旧版解释器可能直接报语法错误。--version能跑通说明依赖缺失的问题已经被解决接下来可以放心进入实际扫描。如果提示缺少模块常见做法是用 pip 安装依赖pip3 install requests装完后重新执行--version。依赖问题基本到此为止不需要额外配置任何东西。2.2 跑通第一次真实扫描环境没问题后第一次扫描建议先拿一个自己可控的测试站点练手别一上来就扫线上系统。扫自己搭的某跨平台系统 Demo 或某个本地靶场既能看懂输出也不会有授权风险。# 最小命令指定目标、指定字典、纯文本输出 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt --format plain-u是目标 URL注意要带协议前缀写成http://192.0.2.10/而不是192.0.2.10工具能省很多事。-w指定字典路径这里用的db/dicc.txt是项目自带字典覆盖常见目录名和后缀。--format plain让结果以纯文本输出比默认带颜色的表格更合适第一次观察也方便后续重定向到文件。跑完你会看到两类输出请求过程里不断出现的是被过滤的状态码比如 404真正被记录下来的是存在有效响应的路径。第一次跑不需要追求速度或深度重点是让「目标 - 字典 - 结果」这条链路通起来。2.3 快速验证扫描结果是否合理扫描结果不是所有 200 都可信首次跑通后要确认一下工具报出来的路径里哪些是真实存在的资源哪些是目标站点的「统一响应」。# 对扫描结果里找到的路径单独发一条请求确认响应内容 curl -i http://192.0.2.10/admin/curl -i会把响应头和正文都打出来。一个正常的/admin/要么返回登录页要么返回 301 跳转如果一个根本不存在的随机路径也返回同样的 200说明目标站点把所有未知请求都统一打回 200 页面这时候工具报出来的「发现」大半是噪音。这个判断习惯一定要从第一次扫描就开始养成否则后面扫得越深垃圾结果积累得越多。3. 参数调优把扫描速度和准确率调到你想要的样子最小命令能跑通后核心问题变成怎么控制扫描的强度、怎么过滤无效结果、怎么让字典贴合目标。这些全藏在参数里也是熟手和新手拉开差距的地方。3.1 线程、超时与延迟先调这三项并发数、超时时间、请求间隔这三个参数直接决定扫描是快还是稳。它们之间相互牵制不能只拉高一个。参数作用推荐初始值适用场景-t 10并发线程数10常规内网/测试环境--timeout 10单次请求超时10目标响应较慢时--delay 0.5请求间延迟0.5目标有明显速率限制时先解释线程数。线程开得越大单位时间内发出的请求越多扫描越快但代价有两个一是目标服务器可能直接断连或触发访问控制二是本机文件描述符消耗加剧扫描器本身可能出现假死。我不建议一上来就填 50先用 10 跑一圈观察响应延迟和错误率再决定要不要加。超时时间针对的是慢速响应。如果目标页面平均要 8 秒才返回--timeout默认值可能等太久拖慢整体节奏反过来目标响应飞快超时设太长反而白等。常见做法是先手工访问一个页面掐表看响应时长再往上翻一倍设超时。--delay是给「温柔模式」用的。目标如果有访问频率限制或者这是一台正在承载业务的机器每发一个请求前强制间隔一段毫秒数能明显降低触发拦截的概率。代价是扫描时间线性拉长一般只在目标确实限速时才开。3.2 状态码过滤别让 404 刷屏也别误杀 301扫描器默认会汇报多种状态码但真正该关注的是 200、301、302、401、403 这些有含金量的响应。大量 404 混在输出里会把有效结果淹没这时需要显式排除。# 显式排除 404只输出其他状态码 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -x 404 # 多个状态码用逗号分隔 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -x 404,400,405-x后面跟的是你要排除的状态码列表。这个参数比--include-status只保留某些状态码更好用因为一个站点可能同时存在多种状态码200 的页面、301 的跳转、401 的接口各有各的价值只排除确定没用的 404/400 更稳妥。有个细节容易踩有些站点对不存在的路径返回 302 或 403而不是 404。如果你只排除了 404这些假路径还是会混进结果里。遇到这种情况先手工试几个随机路径确认目标站点的「不存在响应」到底长什么样再决定要排除哪个状态码。这一步属于典型的「先摸底再过滤」比拿到结果后一条条手工筛高效得多。3.3 扩展名与递归扫描让字典更贴合目标站点默认字典覆盖的路径很广但目录扫描真正的威力在于「针对性」。目标站点的技术栈会直接决定哪些文件值得探测PHP 站点的.php、.inc、.bakJava 站点的.jsp、.do、.xmlWindows 服务器的.asp、.aspx。# 在通用字典之外追加探测常见敏感后缀 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -e php,txt,zip,bak # 开启递归扫描限制递归深度为 2 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -r --recursive-depth 2-e参数是在已访问的路径上逐个尝试追加这些后缀。比如字典里有一条/backup加了-e zip,bak后扫描器会额外请求/backup.zip和/backup.bak这比字典里硬塞几百条组合路径高效得多因为后缀枚举是在运行时动态拼接的。-r开启递归扫描。默认行为是只扫了一层开启后扫到/admin/这样的目录会继续扫/admin/下的子路径。--recursive-depth 2限制最多往下钻两层避免在目录层级很深的站点上无限套娃。注意递归会显著拉长扫描时间对大型目标建议先不递归跑完一层找出有价值的目录后再单独对它们做二次扫描。4. dirsearch 实战避坑五条血泪经验用这个工具的时间长了会发现大部分「结果不对」不是工具坏了而是对目标站点的特性判断失误。以下五条是几乎每个用 dirsearch 的人都会遇到的坑按「现象 - 原因 - 解决」写清楚。4.1 自定义 404 页面导致的假阳性刷屏现象扫描结果里出现大量 200 状态码点开一看全是同一个「页面未找到」的提示页。整个扫描报告失去参考价值。原因目标站点没有使用标准 404 状态码而是对所有未知请求统一返回 200 加自定义提示页。dirsearch 只认状态码不认页面内容所以把这堆假页面当成了「发现」。解决先用curl -i http://目标/一个不存在的路径确认目标对未知请求的响应特征拿到「不存在页面」的固定特征比如统一的标题或关键字再决定用哪种方式过滤。最简单的是确认它是不是固定 200如果是就在扫描时配合排除逻辑或后续用脚本按关键字清洗结果。另一个有效手段是观察这类页面的响应大小用--min-response-size把小于某个字节数的响应直接忽略因为自定义 404 页通常体积固定且偏小。4.2 线程拉高后扫描器「假死」现象线程数设到 30 以上扫描跑到一半命令卡住不动既不输出新结果也不结束只能强制中断。原因本机可用 socket 连接数达到上限或者目标服务器触发并发限制后不再响应新连接扫描器等待超时的大量线程相互挤占资源。解决降低线程数加超时时间必要时加请求间隔。我的经验是内网测试目标-t 15已经很快公网目标用-t 8更稳。如果一定要追求极限速度可以分多个终端分别跑不同字典对同一个目标做拆分扫描而不是靠单条命令堆线程。拆分扫描的额外好处是某一处崩了不影响整体进度。4.3 扫描到一半被目标封禁 IP现象扫描前期一切正常中途开始所有请求都返回 403换一个路径也一样明显不是路径问题。原因请求频率或请求总数触发了目标所在网段的访问控制规则封禁了来源 IP。很多框架和服务商会带速率限制与连续错误检测dirsearch 的高并发特征很容易踩中。解决降低线程、加入--delay请求间隔让请求节奏更接近人工访问。更重要的建议是扫描前先确认目标是否存在速率限制如果一台机器顶不住就用合规的固定出口和分批扫描策略。不要试图用更强的并发去对抗封禁机制那只会让封禁时间更长。4.4 路径能扫出来但浏览器打不开现象扫描报告里明明记录了一段路径但放进浏览器访问却白屏或连接失败。原因最常见的是协议不匹配——目标站点强制跳转 HTTPS而扫描命令里写的是http://或者反过来。另一种情况是目标站点对Host请求头有校验扫描器默认请求头里的 Host 与目标 IP 不匹配被服务器直接拒绝。解决先确认站点到底走 http 还是 https把-u参数写对。dirsearch遇到 HTTPS 站点时证书报错是正常现象配置中可以跳过证书校验。如果目标有虚拟主机需要用-H Host: 实际域名把正确的 Host 头带上。这个坑的精髓在于扫描器看到的响应和你用浏览器看到的响应只有在请求头完全一致时才是同一回事。4.5 Windows 下字典乱码导致路径识别失败现象在 Windows 上跑扫描字典里的中文路径全部变成乱码目标站点返回的结果也异常。原因字典文件编码与 Python 解释器默认编码不一致。项目自带的字典文件通常是 UTF-8但 Windows 控制台默认编码可能是 GBK导致读取时出现乱码。解决把字典文件另存为 UTF-8 编码或者在命令前用chcp 65001把控制台代码页切到 UTF-8。养成习惯拿到任何字典先看一眼编码不确定就统一转成 UTF-8 再使用。这个坑在 Linux 上基本不会出现Windows 用户需要格外注意。5. 把扫描结果接进工作流输出、过滤与脚本化批量扫描多个系统时dirsearch的价值不只是「跑完看报告」更在于把结果变成可复用、可交接的数据。这一步做得好后续验证和二次测试能省掉大量手工操作。5.1 输出格式怎么选dirsearch支持多种输出格式不同场景选不同格式是提高效率的关键。# 导出纯文本结果 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -o result.txt # 导出 JSON 格式 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -o result.json-o指定输出文件配合--format可以控制文件格式。纯文本适合人肉快速浏览JSON 适合程序处理。如果你打算把结果交给其他团队或写脚本自动验证建议直接存 JSON如果只是自己看纯文本更直观。导纯文本时建议同时保留终端里的完整输出因为终端输出包含时间信息能帮你判断扫描节奏是否正常。5.2 用脚本把结果变成待确认清单扫描报告里记录的是「存在响应的路径」不等于「存在有用的资源」。下一步通常是批量访问这些路径确认响应内容和页面标题把「疑似后台」「疑似备份文件」「疑似接口」分类标记出来。# 从实际使用的文本格式里提取 URL 列逐条请求并打印状态码 # 注意列序号取决于你输出的格式先用 head 看一行再做调整 head -n 5 result.txt grep -E 200|301|302 result.txt | awk {print $2} url.txt这段命令的思路是先看结果格式再用 grep 过滤出高价值状态码行用 awk 抽出 URL 列。真正动手前一定要先head -n 5看一眼行结构——不同版本默认输出的列顺序可能不同直接抄网上脚本经常在这里翻车。抽出来的 URL 列表可以和 curl 循环配合批量确认每个路径的响应内容。5.3 批量扫描多个目标的分时策略手上有多个目标时不建议用一条命令同时扫全部站点因为单个目录扫描的资源消耗已经不小。常见做法是写一个循环按顺序逐个扫描并把每个目标的结果单独归档。#!/bin/bash targetshttps://site-a.example/ https://site-b.example/ https://site-c.example/ for t in $targets; do name$(echo $t | sed s#https\?://##;s#/#_#g) python3 dirsearch.py -u $t -w db/dicc.txt -x 404 --format plain -o result-${name}.txt sleep 2 done循环里每个目标之间留 2 秒间隔是防止连续扫描不同站点时网络连接状态异常。name变量把 URL 转成文件名前缀避免结果互相覆盖。这里有个细节目标站点如果是同一台服务器上的多个虚拟主机串行扫描更安全如果是完全不同的网络可以考虑并行扫两个但每加一个并行任务就要重新评估线程数。6. 进阶玩法面向技术栈的定向字典与常用组合当你把前面这些参数都玩熟之后dirsearch 的常规扫描已经满足不了你了。剩下真正值得投入的方向是「让字典自己学会说话」——针对目标站点的技术栈、框架特征、常见备份习惯构造专属的路径字典组合。举个例子。如果登录页面是 PHP 风格的 URL接口返回的响应头里带有特定框架标识那么通用的db/dicc.txt就过于保守了。我会在扫描前做三件事先跑一遍页面收集登录入口和静态资源路径再查目标使用了什么框架或中间件最后按技术栈补齐字典——PHP 站点补上.php、.inc、.swp、.bakNginx 站点看有没有.git目录泄漏Java 站点把.jsp、.do、.xml、.jar塞进-e参数里。# 一个我来回用了很多次的组合 # 排除 404追加敏感后缀限制递归深度忽略体积过小的响应 python3 dirsearch.py -u http://192.0.2.10/ -w db/dicc.txt -e php,zip,bak,txt -x 404 --min-response-size 200 -r --recursive-depth 2--min-response-size的作用值得多说一句。很多站点对不存在的路径会返回一个体积很小的默认响应比如纯文字提示、空页面而这些响应在状态码层面可能是 200单靠-x 404拦不住。设置最小响应字节数后这些空壳响应会被直接忽略报告里留下的都是真正有内容的资源。这个参数配合-e使用效果最好——因为追加后缀扫描会产生大量请求过滤条件越严格后期人工验证越省力。有一次我就是靠这套组合找到了一份遗留的.sql备份文件当时通用字典扫了三轮都没发现它。后来我把「先摸技术栈 - 再定向补字典 - 严格过滤」固化成自己的标准流程再也没用通用字典大海捞针过。希望这些习惯和参数组合能帮到你让你拿到dirsearch-master.zip后少走一段弯路。本文还有配套的精品资源点击获取