干了这么多年Web安全评估我敢说目录扫描算得上是出活率最高、性价比最离谱的一项测试手段。很多看似固若金汤的系统最后突破口往往不是0day也不是什么高级攻击链而是Web根目录下某个不该存在的.bak文件、一套没加访问控制的测试接口或者干脆是暴露在外的.git源码仓库。今天这篇就把目录扫描这摊子事彻底聊透重点围绕dirsearch这个工具、字典爆破的核心逻辑以及敏感目录泄露挖掘的完整思路来展开。不管是刚入门的安全新人还是需要给自己的站点做自查的运维开发都能从里面拿到可以直接用的东西。1. 敏感目录泄露的根源与风险1.1 泄露是从哪儿来的先说一个我自己的判断绝大多数敏感目录泄露根本原因就四个字——便利优先。开发阶段图省事把后台路径命名为/admin、/manage这种一眼就能猜到的单词测试阶段为了联调方便把/api_debug、/swagger-ui.html这种调试入口直接留在生产环境运维阶段做备份习惯性地在站点根目录打一个backup.zip、site_2024.tar.gz。这些操作在当时看来都是“临时搞一下”结果“临时”就变成了“永久”。这类问题有多普遍我在授权渗透测试里十次有六七次都能在目标站点扫出至少一个敏感路径。有的直接是后台登录页有的是一份包含数据库连接信息的配置文件最夸张的一次是直接把整个网站的源码包挂在根目录下连压缩密码都没设。所以别觉得这种漏洞“低级”就可以忽视在实际攻防里它往往是撕开防线的第一道口子。1.2 泄露会造成什么后果敏感目录泄露的威胁等级要看泄露的是什么类型的文件。我们把风险从低到高排一下低危一些无关紧要的静态资源目录比如/images、/css这类目录泄露本身不致命但会帮助攻击者了解站点结构为后续精准攻击提供信息支撑。中危后台管理入口、测试页面、旧的接口文档比如/admin、/test.php、/api_doc.html。攻击者拿到这些路径后等于省去了大半的信息收集工作可以直接对登录接口和业务接口发起攻击。高危配置文件、备份文件、源码包、版本控制目录比如/.git/、/.svn/、/config.php.bak、/web.zip。一旦这些被下载下来数据库账号密码、加密密钥、业务逻辑、历史漏洞就全部暴露了性质等同于源代码级泄露。致命云凭据文件、内网代理配置、运维平台入口比如/aws_credentials、/jenkins、/kibana。这类信息可能直接打通从外网到内网的跳板属于严重安全事件。需要注意的是目录扫描不是为了“找出一个后台地址然后尝试登录”而是为了评估攻击者在不接触任何内部信息的情况下通过公开可访问的路径能拼凑出多大的攻击面。理解了这一点你就知道为什么字典选型和扫描策略这么重要了。2. dirsearch工具能力深度拆解2.1 为什么是dirsearch市面上做目录扫描的工具不少常见的有御剑、dirb、gobuster、wfuzz以及Burp Suite里自带的Intruder。我为什么主力推荐dirsearch三个原因第一它是纯Python实现的跨平台能力好Linux、macOS、Windows都能跑依赖也简单第二它的功能设计非常贴近实战比如递归扫描、指定扩展名、指定HTTP方法、多线程、请求速率控制基本上你想要的它都有第三它的输出格式丰富文本、JSON都能导方便后续分析。拿御剑这类Windows图形化工具来对比御剑胜在“开箱即用”双击就能扫但它的问题是线程和字典耦合得太深自定义能力弱而且很久没更新了。dirsearch虽然需要敲命令但熟练之后效率远高于图形化工具尤其是在批量测试、结果自动化处理这些场景下命令行工具的优势是碾压级的。2.2 核心参数详解和常用组合dirsearch的常用参数可以参考这个表格参数作用实战建议-u/--url指定目标URL可以多次使用批量扫描多个目标-w/--wordlist指定字典文件默认用自带字典实战建议换成自定义字典-e/--extensions附加扩展名常用php,asp,aspx,jsp,txt,bak,zip-r/--recursive递归扫描子目录强烈建议开启但要配合--max-recursion-depth限制层数-t/--threads线程数内网目标可以开到20外网建议10以内-x/--exclude-status排除状态码默认已排除404建议再加403、400--random-agent随机User-Agent推荐开启避免被简单WAF识别--batch批量模式扫描时遇到提示自动选择默认项无人值守必备-o/--format输出结果建议-o result.json --format json方便后续分析基础用法长这样dirsearch -u https://target.com -e php,txt,bak,zip -t 10 --random-agent --batch这行命令的意思是用10个线程扫描目标附加php、txt、bak、zip这四种扩展名用随机UA防止简单拦截遇到交互提示自动选默认项。扫描结果默认会保存到reports/目录下。我自己的习惯是再加两个参数dirsearch -u https://target.com -e php,txt,bak,zip,json,xml -t 10 -r --max-recursion-depth2 --random-agent --batch -o target_scan.json --format json-r开启递归后工具扫出来的每个目录都会往下继续挖适合做大面积巡检但递归层数一定要限制否则遇到无限递归的目录结构会跑到天荒地老。--max-recursion-depth2表示只往下追两层这个深度在大多数场景下已经够用了。2.3 常见安装问题unable to locate package dirsearch在Kali或者Debian系系统上你大概率会遇到下面这个报错sudo apt install dirsearch Reading package lists... Done E: Unable to locate package dirsearch这种报错的原因是该系统版本的软件源里根本没有dirsearch这个包。Kali的软件源需要滚动更新Debian稳定版更是往往不会收录这类工具。解决办法有两个第一个办法直接从GitHub拉取源码运行这也是我最推荐的方式git clone https://github.com/AstroWen/star_destroyer.git cd dirsearch pip3 install -r requirements.txt python3 dirsearch.py -u https://target.com注意不同时期dirsearch的仓库地址可能有变化直接去GitHub搜索dirsearch找Star数最高的那个就可以。这类工具的更新频率很高源码方式能保证你拿到的是最新版本比你用apt装老版本靠谱得多。第二个办法如果你一定要用包管理器安装先更新索引再看包源里有没有sudo apt update apt search dirsearch如果apt search也找不到就换回源码方式。另外如果提示ModuleNotFoundError: No module named requests之类的依赖缺失执行pip3 install -r requirements.txt就能解决。3. 字典爆破的原理与字典选型3.1 字典爆破为什么是目录扫描的灵魂dirsearch本身只是一个“发请求、看响应、做判断”的引擎真正决定扫描效果好坏的是你喂给它的字典。字典爆破的本质是枚举把字典里的每一个路径拼到目标URL后面发请求根据HTTP状态码和响应内容判断这个路径是否存在。用个比方来解释dirsearch就像一把精密的钥匙字典就是钥匙上一个个齿痕钥匙的材质再好如果齿痕对不上锁芯也一样打不开门。所以目录扫描不是“跑了工具就完事”而是要花心思去研究目标、积累字典、构造字典。我在项目里经常看到有人拿着默认字典无脑跑一圈然后报告里写“未发现敏感路径”实际上换个合适的字典分分钟就能扫出东西来。3.2 字典来源与精选路径字典可以从三个渠道获得工具自带的字典dirsearch在db/目录下自带了一些字典比如wordlist.txt、common.txt适合做快速初检覆盖面一般。社区维护的大型字典比如SecLists项目的Discovery/Web-Content目录里面的raft-large-directories.txt、common.txt、big.txt都是好东西。SecLists的优势在于分类清晰、样本量大几万条路径词条基本覆盖了常见命名习惯。自己沉淀的字典这个才是拉开差距的地方。我会把平时测试中命中率高的路径单独存到一个文件里定期整理。比如各种备份文件命名规则、常见后台路径变体admin、houtai、manage、management、system、开发阶段遗留的调试接口等。我个人经常在字典里用到的路径词条按用途分类分类典型路径/文件名后台入口admin, manage, manager, console, dashboard, systems, backend, houtai备份文件web.rar, web.zip, site.rar, site.tar.gz, backup.zip, www.zip, 域名.zip配置文件.env, config.php, config.php.bak, setting.ini, web.config, application.yml版本控制.git, .git/config, .svn, .svn/entries, .hg调试接口api, api_debug, test, phpinfo.php, swagger-ui.html, debug, trace通用目录upload, uploads, file, files, data, database, download, tmp, temp, old, test, demo3.3 扩展名的组合策略光有路径还不够扩展名组合是一门学问。同一个路径词条比如config可以衍生出config.php、config.php.bak、config.txt、config.zip、config.xml等等。dirsearch的-e参数允许你指定多个扩展名它的底层逻辑是对字典里的每个路径词条分别追加这些扩展名去请求。那扩展名怎么选一个基本判断标准是看目标站点的技术栈。如果目标响应头里的X-Powered-By显示PHP那重点测php和phtml如果从登录页或URL后缀能看出是.NET那重点测aspx和asp如果是Java系Spring Boot等那重点测json、action和do。通用的兜底扩展名组合是txt,bak,zip,json,xml——这些跟语言无关配置文件、备份文件最常见的格式就是这些。这里有个我踩过坑的经验不要一上来就挂一大堆扩展名。扩展名越多请求数量越多扫描时间成倍增加同时也更容易触发目标的频率限制。合理做法是先做一轮“无扩展名基础扩展名”比如只加php快速把目录结构摸清楚再针对可疑目标做第二轮带更多扩展名的精细化扫描。4. 实战敏感目录泄露挖掘的完整操作流程4.1 扫描前的授权确认在进入正题之前必须先把红线讲清楚目录扫描只允许在你有明确授权的目标上开展比如你自己公司的系统、客户委托的渗透测试项目、或者你搭建的本地靶场。未经授权扫描他人系统不管出于什么动机都是违规甚至涉嫌违法的高风险行为。下面整个流程都默认你已经有合法授权了。4.2 第一步信息收集是扫描的启动器不少人的习惯是拿到一个URL就直接开扫其实这不是最优做法。花一两分钟做信息收集能让后续扫描精准得多。具体看这几个信息指纹识别目标是什么Web容器Nginx/Apache/IIS什么后端语言PHP/Java/ASP.NET什么框架这些决定了你选什么扩展名、重点看什么路径。工具可用whatweb、Wappalyzer也可以直接看响应头。子域名收集如果授权范围是整个域名先把子域名枚举出来重点测那些“不像生产环境”的子域比如test.*、dev.*、api.*。很多团队对主站管控严格却忽略了测试子域的安全配置那里往往藏着惊喜。端口服务确认目录扫描的本质是Web服务的路径枚举但如果目标还有别的端口开放着Web服务比如8080的管理台、9090的监控面板这些也不要放过。用nmap扫一遍全端口把Web服务都列出来依次扫。4.3 第二步三种扫描策略与命令模板信息收集做完我会按下面的策略分三轮扫描目的不同参数配置也不同4.3.1 第一轮快速广度扫描目的是快速了解目标的整体目录结构和大致攻击面用中等规模的通用字典线程适中扩展名挂常用几个。dirsearch -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/common.txt -e php,txt,zip,tar.gz -t 15 --random-agent --batch -o scan_round1.json --format json这一轮通常几分钟就能跑完。扫完先不急着深挖重点看有没有.git、.env、backup、admin这类高价值路径有的话优先验证。4.3.2 第二轮深度递归扫描第一轮扫出来的目录比如/api/、/uploads/、/includes/每个都可能还有自己的子目录和文件。这一轮用递归模式往下挖同时调大字典规模。dirsearch -u https://target.com/api -w /usr/share/seclists/Discovery/Web-Content/raft-large-directories.txt -e php,json,xml,txt,bak -t 10 -r --max-recursion-depth2 --random-agent --batch -o scan_round2.json --format json递归扫描很吃时间所以我只会挑第一轮里状态码为200、301且不是死循环或者判断出“确实存在目录”的目标来做第二轮不会对整个域名无脑递归。4.3.3 第三轮定向专项爆破前面两轮是“广撒网”第三轮是“定点清除”。针对明确的目标比如已知某个后台路径围绕它做变体枚举dirsearch -u https://target.com -w /path/to/custom-admin-dict.txt -e php,html,bak,zip -t 8 --random-agent --batch --user-agent Mozilla/5.0 -o scan_round3.json --format json这轮也可以用Burp Suite的Intruder来做好处是能看到完整的请求响应包方便观察服务器处理差异。我的习惯是dirsearch负责“发现”Burp负责“深挖”和“验证”两者配合使用。4.4 结果解析和验证扫描结果出来之后不能只看状态码就下结论。我的处理原则是“三个看”看状态码200是存在且可访问301是存在且跳转401/403是存在但被限制访问注意403也可能是WAF统一拦截不存在路径导致的需再验证500是服务器错误有的服务器对不存在路径也会返回500要结合上下文判断。看响应体大小dirsearch输出的结果里包含响应体长度。当一个路径返回200但是响应体和首页一模一样时多半是前端路由的兜底逻辑并不是真实目录。反之如果响应体长度和其他路径明显不同即使状态码是404也要注意可能存在假404的情况。看响应内容最靠谱的验证方式是把返回的页面内容拉下来看一眼。我一般会写个小脚本或者直接在浏览器里访问那个路径看页面上有没有关键词、有没有报错信息、有没有跳转动作。验证之后把确认有问题的路径按风险等级记录到报告里附上截图和访问方式这一步就完成了。5. 常见问题与排查技巧实录5.1 识别“假404”和“泛解析”实站里经常遇到一种情况随便访问一个不存在的路径服务器也返回200或者200状态码一段固定页面。这种叫泛解析/优雅降级尤其在前后端分离的SPA站点里特别常见——所有路径都会被index.html接管后端响应200前端再用路由去匹配。如果目标有这种情况单纯看状态码基本废了。我的应对手段是两招第一看响应体大小如果扫出来的十几个路径响应体长度全都相同极其可疑第二换工具或者写脚本发送两种请求一种是不存在的随机路径一种是字典里的路径对比响应的差异比如标题、关键字、响应头。如果两者毫无差异那扫出来的路径大概率是无效的。dirsearch有一个--exclude-status参数但对付这类场景还不够得靠响应体判断。5.2 扫描速度与服务稳定的平衡线程开太高容易把目标打挂或者被WAF封IP开太低又等得人心急。我踩过的坑是有个目标用的是老旧的Windows ServerIIS我把线程开到30结果目标直接服务不可用整个测试窗口被浪费了大半天。后来我就定了个规矩外网目标线程控制在10以内内网目标最多20同时加一个--delay参数在请求之间插入间隔比如--delay0.3表示每个请求间隔300毫秒。这样既能维持扫描强度又不容易引起服务异常或触发硬性拦截。如果目标有WAF或者目标比较重要我会把扫描时间拉长、频率降低用“慢工出细活”的方式绕过速率检测。配合--random-agent使用效果更好。5.3 结果输出与后续联动dirsearch输出成JSON格式后我通常会直接用jq做二次过滤比如只保留返回200和301的路径jq [.results[] | select(.status 200 or .status 301)] scan_round1.json这样能快速把有效路径筛出来再结合Burp Suite做爆破或者人工访问验证。另外dirsearch还支持--csv格式方便直接用Excel打开做表格。测试报告需要附截图但截图证据一般来自后续浏览器的访问验证。5.4 一个被我反复使用的组合思路最后分享一个小组合能很大程度提高敏感目录挖掘的完整度。我的标准流程是第一步nmapwhatweb把目标的技术栈和端口摸清楚第二步dirsearch快速广扫拿到候选路径第三步对高价值路径换大字典再定向爆破第四步用Burp Suite的Intruder对可疑路径做扩展名和参数枚举第五步把发现的所有路径全访问一遍把页面内容存档留证。这套流程看起来很笨但非常管用。自动化工具负责把“可能性”筛出来人工负责把“确定性”验证出来两者缺一不可。6. 一些关于字典和工具的心得目录扫描这行的入门门槛很低装个工具跑一下谁都会但真正拉开差距的是对“路径命名规律”的理解和日常积累。比如中文团队习惯命名houtai英文团队习惯backend老项目可能有test、demo这种路径新项目可能用gateway、auth这类微服务风格的路径。这些东西不会出现在默认字典里只能靠日常测试一点点记下来。我自己会把每次测试中高命中的路径、文件后缀、目录命名习惯都整理到一个笔记里隔几个月做一次分类和去重。时间长了这套自定义字典的命中率远超任何通用的公开字典。有时候甚至不用扫描光凭经验猜就能直接猜到常见后台路径和备份文件名的组合。还有一点想说目录扫描只是敏感信息发现的第一步扫到路径之后一定要跟进验证和利用——确认它是不是真的泄露了敏感内容、泄露的内容能否被进一步利用、影响范围有多大。只扫不验测试报告就是一堆“疑似”和“可能”价值大打折扣。如果你打算长期做这块我建议把dirsearch的源码翻一翻看看它发请求、解析响应、去重、递归的实现方式。理解了工具内部逻辑之后遇到奇怪的目标系统时你才不会一头雾水也能更灵活地组合参数去适配不同场景。这套东西看起来是“体力活”但底层拼的还是思路和经验。
