ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

dirsearch目录扫描与字典爆破:敏感目录泄露挖掘实战全攻略

dirsearch目录扫描与字典爆破:敏感目录泄露挖掘实战全攻略 拿到一个目标之后第一件事不是急着打点、找漏洞而是做信息收集。信息收集做得好不好直接决定后面所有动作的节奏和命中率。而在信息收集这一环里目录扫描又是性价比极高的一项不需要太高权限不需要太复杂的工具一条命令跑下去往往就能翻出备份文件、测试接口、管理后台这些本不该放在那里的东西。今天想和你认真聊聊 dirsearch、字典爆破 和 敏感目录泄露挖掘 这一整套思路从工具安装到实战参数从字典构造到误报排查把我踩过的坑和验证过有效的经验一次说完。很多人第一次接触 dirsearch是因为在 Kali 里执行apt install dirsearch直接报unable to locate package dirsearch还没开始扫描就被安装劝退了。别急这是入门第一道坎我会从这个问题讲起把工具选型、原理逻辑、实操参数、字典玩法、泄露挖掘和排错技巧全链路拆开。这套内容适合刚入门的安全测试新手也适合已经跑过一阵子但总觉得扫描结果不准、不深、不好用的人。不管你是做授权渗透测试、企业自查还是只是研究自己搭建的靶机这篇都能帮你把目录扫描从会跑命令提升到懂结果、会判断、能深入的层次。1. 目录扫描在信息收集中到底扮演什么角色1.1 为什么敏感目录会自己送上门先说个现实问题为什么目录扫描这种东西到现在依然是重点按理说稍微有点经验的运维都知道不该把备份文件放在 Web 目录下但现实中泄露的例子一抓一大把。原因不外乎这几种开发者图省事把config.php.bak丢在项目根目录交接时没清理测试用的phpinfo.php运维把压缩包site_2023_backup.zip传到网站目录里下载之后忘了删甚至还有把.git文件夹整个暴露在外的情况。这些文件的共同点是它们不一定是漏洞但它们是信息泄露。在真实测试里一条.git/config的响应就可能让攻击者拿到源码仓库的地址甚至进一步利用版本历史还原出数据库密码、API Key。目录扫描的价值就在这里——它不是直接利用漏洞拿权限而是帮你找到那些暴露在外、本不该暴露的资源为后续测试提供支点。所以敏感目录泄露挖掘本质上是一场找遗留物的游戏。你猜不到开发者会犯什么错但你可以用字典去枚举那些常见的命名和路径把历史配置错误、备份文件、调试接口从角落里翻出来。1.2 目录扫描工具的工作原理dirsearch 这类工具的原理一句话总结就是批量发 HTTP 请求根据响应判断路径是否存在。你给它一个目标 URL 和一个字典文件它会把字典里的每一个路径拼到 URL 后面逐个请求再通过状态码、响应长度、响应标题、重定向位置等信息判断这个路径是真的存在还是返回了一个假 200。这里有个新手容易忽略的关键点目录扫描不等于端口扫描。端口扫描看的是端口通不通目录扫描看的是路径在不在。同一个 IP 的 80 端口和 8080 端口可能对应完全不同的 Web 服务同一个域名下/admin可能返回 200/administrator可能返回 404。所以扫描前必须搞清楚你到底在扫什么是域名、是 IP 加端口、还是某个具体的子路径。理解了原理你就能理解为什么响应码判断是目录扫描的核心。200 通常代表存在301/302 代表重定向需要判断重定向去了哪403 代表存在但禁止访问404 代表不存在。但现实比这复杂得多很多网站对所有不存在的路径都返回 200比如 SPA 应用这时候就得靠响应大小和标题来二次判断。1.3 工具选型为什么首选 dirsearch目录扫描工具不止一个常见的有 dirsearch、gobuster、ffuf、wfuzz、御剑Windows 下常用等。我个人的经验是日常测试首选 dirsearch尤其是跨平台和字典直接可用的场景。工具语言/平台优势劣势适用场景dirsearchPython字典丰富、支持递归、随机 UA、代理、IDN 域名相对吃内存超大字典下线程不宜太高日常全流程扫描gobusterGo单二进制、速度极快、支持 DNS/目录/Vhost 模式默认不带字典需另配快速粗扫ffufGo高度灵活、可做参数/接口模糊测试配置更复杂新手门槛略高精准 FUZZwfuzzPython可做复杂 payload 注入速度一般较老自定义复杂场景御剑Windows GUI图形化、适合新手老牌工具字典老旧跨平台差快速试水dirsearch 的优势在于生态完整自带一批不错的字典支持通配符递归扫描还能通过--exclude-status排除状态码、--random-agent随机 UA基本覆盖了探索阶段的绝大部分需求。它不是最快的但它是整体体验最稳的。当你习惯它的参数和输出格式之后效率并不比 gobuster 差多少。2. 从零装好 dirsearch别卡在第一步2.1 先解决unable to locate package dirsearch这是搜索热度最高的问题。在 Kali 或 Debian/Ubuntu 上跑apt install dirsearch很直接报unable to locate package dirsearch。原因是这些发行版的默认软件源里压根没有 dirsearch 这个包。它不像nmap、sqlmap那样进了官方源所以你 apt 装不上。这个报错和网络、源配置不一定有关系单纯是源里没有。解决办法有三种方法一pip 安装pip3 install dirsearch装完后直接用dirsearch命令启动。这是最推荐的方式跨平台、依赖自动装好、升级也方便。注意如果你的系统是外部 Python 环境管理比如 Ubuntu 的 PEP 668 限制可能要加--break-system-packages或者用虚拟环境。方法二git clone 源码运行git clone https://github.com/maurosoria/dirsearch.git cd dirsearch python3 dirsearch.py -h这个方式对源码学习者很友好也能确保拿到最新版本。方法三如果坚持 aptKalisudo apt update sudo apt install dirsearch部分 Kali 版本在做过完整apt update之后能找到包。但如果你用的是 Ubuntu、Debian 原生源大概率还是找不到。建议不要在这个问题上死磕直接 pip 或 git clone 更省时间。在写这篇经验帖之前我特意在几台不同的环境上重新验证过一遍Debian 12 上 pip 安装最顺Kali 新版里 apt 偶尔能用但版本偏旧还是推荐 pipWindows 上直接用pip install配合dirsearch.exe入口也可以跑不过更推荐装个 WSL 再操作兼容性稳得多。2.2 验证安装和基本参数装完先跑一下dirsearch -h会看到一大串参数。这里挑最常用的几组说dirsearch -u https://target.com -e php,bak,zip -t 50 --random-agent -x 404参数分解-u指定目标 URL-e指定追加的扩展名比如你期望找到.php、.bak、.zip文件-t线程数常见 20~100--random-agent每次请求随机 User-Agent能降低被简单封禁的概率-x排除状态码比如-x 404直接不看 404能减少输出垃圾信息还有一个特别实用的参数是--exclude-sizes用来排除响应大小相同的页面。比如一个网站对所有不存在的路径都返回同一个 404 页面这个 404 页面大小固定是 12045 字节那么所有响应大小为 12045 的路径基本都可以判死。你可以先手动访问一个不存在的路径记下响应大小然后--exclude-sizes 12045扫出来的结果立刻清爽很多。2.3 第一次全扫描实践第一次实战我建议你用一个自己搭建的靶机或者本地环境先跑通整个流程。假设你已经装好了 dirsearch执行dirsearch -u http://127.0.0.1:8080 -e php,txt,bak,zip -t 20 --random-agent --format plain扫描完成后dirsearch 会在默认的reports/目录下生成报告文件有 plain、json、csv 等格式。我习惯用--format plain直接看结果同时留一份json方便后续处理。跑通之后再逐步加大字典、增加递归、调整线程。先把基础链路练熟后面谈参数调优才有意义。第一次扫描不要一上来就建 100 线程大字典容易把目标搞挂也会让本机网络资源被占满结果好坏难说。先用小字典小线程跑通再慢慢加量这是所有扫描类工作的通用节奏。3. 字典爆破不是越大越好3.1 理解状态码与置信度字典爆破的目的是用大量路径去试探目标服务器而这个试探结果的解读靠的是 HTTP 状态码。如果你是新手我建议先把状态码的几个关键分支背清楚状态码含义目录扫描中的判断后续动作200OK路径存在且可访问直接记录进一步抓内容、找链接301/302重定向存在但可能跳转到登录页或新地址跟随重定向看落地页内容401/403未授权/禁止存在但禁止访问高价值目标说明路径被保护但可能配置有缺陷404不存在大概率路径不存在过滤掉405方法不允许路径存在但仅限特定方法尝试 POST、PUT 等500/502/503服务端错误路径可能触发异常重点关注可能隐藏参数点或脆弱的脚本但状态码只是第一层判断。我在实际测试中见过很多假 200的情况一个网站把所有不存在的地址都返回 200但页面内容是统一的页面不存在提示。这时候就必须用响应大小来辅助判断。dirsearch 默认会在结果里显示Content-Length同一份响应大小反复出现的基本可以排除。另一个判断技巧是看响应标题Title。如果所有结果里的 Title 都是同一个比如Error Page或404 Not Found那这些路径大概率是误报。如果某条路径的 Title 和大多数不同比如出现了Dashboard、Login那大概率扫到真东西了。3.2 字典来源与选择目录扫描的结果好坏一半看工具一半看字典。很多人一上来就拉一个几千万条的超级字典结果跑了几个小时也没跑完而且命中率低得可怜。字典不是越大越好关键是要贴合目标。我常用的字典来源按优先级排序dirsearch 自带的数据库安装目录下的db/dicc.txt、db/dir.txt、db/dir1.txt、db/dir2.txt、db/dir3.txt、db/php.txt、db/bak.txt等。这些字典做了分类dir2、dir3侧重不同规模的路径bak.txt侧重备份文件。先跑自带字典基本不会空手而归。SecLists网络安全测试界最常用的字典集里面有Discovery/Web-Content/分类包含common.txt、directory-list-2.3-*.txt、raft-large-words.txt等。适合对站点的积累广撒网。自建积累每次实战中命中的路径、响应大小特征、目标技术栈相关的路径都可以沉淀到自己的字典里。这个积累过程时间越长越值钱。选字典的原则是先用小字典快速摸一遍底再用中字典深挖最后用大字典补漏。直接上超大字典等于把时间全耗在无用请求上。3.3 自建字典的思路举一个真实例子。假设你面对的是一个基于 ThinkPHP 开发的站点那www.zip、application/database.php、runtime/、addons/、public/这类路径命中概率就很高如果是一个 WordPress 站点那wp-config.php.bak、wp-content/uploads/、xmlrpc.php、wp-json/wp/v2/users这些路径必须提前放进去如果是 Spring Boot 应用actuator/、actuator/env、swagger-ui.html、v2/api-docs是最值得扫的目标。所以自建字典的第一步是判断目标技术栈。看响应头里的Server、X-Powered-By看首页 HTML 里的框架特征看 cookie 的命名习惯。确定技术栈之后再去收集这个框架常见的敏感路径成功率立刻翻倍。第二步是结合命名习惯补充后缀组合。比如站点主目录叫uploads、backup、temp、test、demo那可以组合出uploads.zip、backup.rar、test.php、demo.sql这类路径。文件名加上常见压缩后缀、源码后缀、数据库备份后缀组合空间很大但命中价值极高。3.4 如何把 burpsuite 爆破字典用在目录爆破上很多人会搜burpsuite 爆破字典然后想着拿来扫目录这个思路我要泼一点冷水。burpsuite 的爆破字典通常是为了登录爆破、参数枚举设计的聚焦在用户名、密码、常见弱口令、参数名上目录扫描需要的是路径、文件名、扩展名两者侧重完全不同。直接把 burpsuite 的爆破字典塞给 dirsearch大概率会扫出一堆无用请求。但也不是完全没用。你可以从 burpsuite 字典里提取通用参数名部分配合接口目录去猜测/admin/api/users这类路径也可以把 burpsuite 抓到的真实请求里的 URL 片段整理出来作为自建字典的语料。本质上字典应该来源自真实的请求模式而不是凭空想象。我这里分享一个简单的自建字典流程# 从 burpsuite 的 HTTP 历史里导出 URL提取路径 cat burp_export.txt | grep -oP ^\S /[^ ]* | awk {print $2} | sed s/^/[/ | sed s/?.*// | sort -u custom_paths.txt # 然后追加常见备份后缀 sed s/$/.bak/ custom_paths.txt custom_paths.txt sed s/$/.zip/ custom_paths.txt custom_paths.txt sed s/$/.php/ custom_paths.txt custom_paths.txt这样得到的字典会非常贴合目标自身的命名习惯。自建字典的威力来自积累不是一蹴而就的。4. 敏感目录泄露挖掘的完整实操流程4.1 高价值敏感路径清单不是所有路径都值得花时间。根据我的经验下面这几类敏感路径一旦命中就值得深入跟踪版本控制泄露类/.git/、/.git/config、/.git/HEAD/.svn/entries、/.svn/wc.db/.hg/备份与压缩包类/www.zip、/backup.zip、/site.rar、/web.tar.gz/db.sql、/database.sql、/mysql.sql/config.php.bak、/.env.bak、/settings.php.old配置文件与环境变量类/.env、/config.php、/database.yml、/web.config/application/config/config.phpThinkPHP 等框架常见接口文档与调试类/swagger-ui.html、/v2/api-docs、/api/swagger/index.html/actuator、/actuator/env、/actuator/health/phpinfo.php、/info.php、/test.php/druid/index.htmlJava 项目常见管理后台与用户枚举类/admin、/administrator、/manage、/system、/login/wp-admin/、/wp-login.php/index.php?mAdmin这类动态路径需要结合框架来判断这些路径在扫描时可能返回 200、301、403 中的任意一种但都值得记录。403 尤其别放过说明路径存在但被人为限制很可能是后台入口。4.2 实战流程从校准到验证我自己的标准流程分四步第一步校准基线。先手动访问两三个肯定不存在的路径比如/this_is_a_404_path_xxq记下响应状态码和响应大小再访问一下首页记下首页的特征。第二步粗扫。用一个中小型字典比如 dirsearch 自带的dir.txt或common.txt加上常用扩展名快速跑一遍目标是把明显的敏感路径找出来。dirsearch -u https://target.com -e php,txt,bak,zip,sql --random-agent -t 50 -x 404第三步过滤和分类。扫描结果出来后不要直接看 200 列表。先用响应大小把误报过滤掉比如所有 12700 字节左右的响应都是同一个 404 页面就排除。然后按状态码和响应特征分类200 的直接打开看内容301/302 的看跳转地址403 的记录为潜在目标。第四步逐个验证与跟进。这一步才是敏感目录泄露挖掘真正发挥威力的地方。光扫出来不算完每一个高价值路径都要手动或工具跟进/.git/能不能直接访问/.git/config如果能立刻用 GitHack、githack 这类工具把源码拉下来。/www.zip如果能下载立刻下载解压重点看数据库配置、密钥文件。/actuator/env如果返回了 JSON里面可能直接有配置项甚至密码。/phpinfo.php返回了 PHP 配置重点看disable_functions、放行目录、扩展加载情况。/admin如果跳转到登录页收集登录框的参数为后续弱口令测试做准备。这个流程跑下来一个目标的敏感目录情况基本就清晰了。4.3 版本控制泄露利用实例在所有敏感目录泄露里.git泄露是最值得展开的一个。因为它意味着攻击者可能拿到完整的源码历史。检测方法很简单目录扫描扫到/.git/HEAD或者直接访问https://target.com/.git/config如果返回的内容包含[core]和repositoryformatversion那就确认存在.git泄露。接着可以用工具把源码拉下来# 以 githack 为例 python3 githack.py https://target.com/.git/这个工具会通过.git/index、.git/objects还原工作区里的文件。还原之后源码就落到了本地后续的代码审计、数据库配置查找就方便了。https://target.com/.git/logs/HEAD还能看到历史提交记录里面可能藏着开发过程中的临时密码、测试 token。.svn泄露也有类似的价值但相比.git更古老现在遇到的概率低一些一旦遇到也别放过。4.4 常见的误报来源与判断手段扫描过程中你会碰到大量干扰项。最常见的几种CDN 或云防护的拦截页。很多网站用了 CDN对所有可疑路径统一返回拦截页面状态码可能是 200 或 403响应大小固定。这种路径是假的误报。自定义 404 返回 200。SPA 框架Vue/React的单页应用最典型不管访问什么路径Web 服务器都返回 index.html状态码 200但内容全是同一个页面。这种要结合 content-type 和响应大小判断。跳转至统一登录页。某些系统会强制所有未认证请求跳转到/login这时候你扫到的大部分 301/302 其实指向同一个登录页面并不是真实路径。对付误报我强烈建议用 dirsearch 的--exclude-sizes。先访问一个不存在的路径拿到响应大小然后扫描时排除它。再加一个--exclude-status 404默认就干净很多。如果还是嫌杂可以用--minimal和--min-response-size之类参数做过滤。5. 常见问题与排查技巧实录5.1 扫描很慢怎么办目录扫描本质上是海量 HTTP 请求速度受限于三个因素目标服务器的响应速度、线程数、字典大小。线程数加大确实能提速但要注意目标服务器可能因为并发过高直接断连或触发防护。稳妥的做法是内网目标可以上 100 线程以上互联网目标建议 20~50 线程起步。如果发现响应速度越来越慢、超时变多应该降线程而不是硬扛。还有一个常常被忽略的因素dict 文件大小和请求频率。一个 100MB 的字典比 10MB 的字典慢得多但命中率不一定会线性提升。我的经验是先用 1~2MB 的小字典粗扫再用 10~20MB 的中型字典补漏最后才根据前两轮结果决定有没有必要上大字典。如果你要扫的目标很多比如一个 C 段或者一批子域名建议串行扫描而不是并行并发多目标同时跑。一次只压一个目标既能保证速度稳定也不会让自己本机网络出问题。5.2 结果可信度问题扫描结果看起来很丰富和实际可验证是两回事。我至少见过三种假象一是泛解析。有些域名把所有子域名都解析到了同一个 IP泛解析你扫任意一个子域名看到的都是同一个站点的同一套路径结果高度雷同没有区分度。二是重定向到登录页。整个系统要求登录所有路径都先跳转/login这时候扫出来的一堆 301/302 没有意义。三是WAF 的拦截响应。某些防护产品对扫描特征有明显的拦截页面并且状态码是 200。这种需要靠响应大小做排除。判断结果是否可信核心手段是交叉验证不要只信一个工具一个字典可以用另一个工具比如 gobuster或更换 UA、更换字典再扫一遍比对结果差异。上一轮扫出来但下一轮没扫到的路径很可能是偶然跳过或拦截了两轮都能稳定出现的路径可信度就高。如果扫到 403值得尝试改一下请求方式。比如用dirsearch -X POST试试 POST 请求、或者给请求加个X-Forwarded-For头有时候能绕过基于 UA 或来源 IP 的拦截。5.3 遇到 WAF 或防护怎么办现在互联网目标几乎多多少少都有防护尤其是国内站点。一个正常的目录扫描可能跑几百个请求就会被拦住。面对这种情况我的策略是伪装成正常访问--random-agent必须开随机 UA 能减少一部分基于 UA 的检测。控制请求频率--delay 1或--delay 2会把速度降下来但能稳定很多。适当降低线程数20 以内相对温和。如果目标支持可以考虑走代理池--proxy 127.0.0.1:8080配合本地代理工具让请求分散到不同出口 IP。但我也要说一句实在话如果你的目标是授权范围内的而防护就是拦你做目录扫描那这件事的优先级可能真的要往后放。与其和 WAF 硬刚浪费大量时间不如去其他入口想办法。扫描是辅助手段不是唯一手段。5.4 安装依赖报错与兼容性最后再集中说一下环境问题。除了前面说的unable to locate package dirsearch我还遇到过这些情况pip3 install dirsearch时报externally-managed-environment这是 Ubuntu 23.04 以后 PEP 668 的限制解决方法是加--break-system-packages或者先用python3 -m venv myenv建虚拟环境再安装。运行时提示ModuleNotFoundError: No module named requests说明 Python 环境里的 requests 库没装。执行pip3 install requests -i https://pypi.tuna.tsinghua.edu.cn/simple即可。Windows 下跑dirsearch.py报编码错乱这通常是终端编码问题建议先chcp 65001切换 UTF-8 编码如果 Python 报 Unicode 相关错误检查系统区域设置。扫描目标出现 SSL 证书错误用-k参数跳过证书验证目标不是标准 443 端口时记得在-u里写明端口。还有一个小技巧如果某个目标的页面里有大量动态参数每次都跳过参数、只跑基础路径会漏掉很多接口。可以先用dirsearch --suffix/之类参数把目录类路径覆盖住再结合页面 JS 提取接口路径配合自建字典做二次补充。写在最后扫描之后才是真正的开始目录扫描、字典爆破、敏感目录泄露挖掘这三件事听起来像三个独立技巧但在我实际测试中它们是完整的一条链目录扫描负责发现、字典爆破负责扩大战果、敏感目录泄露挖掘负责把发现变成可利用的信息。工具只是手段真正值钱的是你对结果的理解和后续动作。扫到.git不拉源码等于白扫扫到.env不检查数据库配置等于白扫扫到后台不去做有针对性的验证也等于白扫。我个人的体会是目录扫描这件事三分靠工具七分靠经验。工具谁都装得上命令谁都会跑但扫到什么值得深挖哪些结果是在浪费你时间这种判断力只能靠一次次实操积累。建议你从自己的靶机、本机环境或者有授权的合法目标开始练手跑过几十个目标之后再回头看最初记录的那些路径你会发现自己对 Web 应用的敏感目录分布已经有了很清晰的直觉。最后再分享一个小技巧每次扫完目标把命中的路径、响应特征、对应技术栈整理到自己的笔记里慢慢形成自己的敏感路径字典。用不了几个月你会发现自己扫描的效率和命中率会高得连自己都惊讶。
返回列表