FFUF与Dirsearch实战：字典构造与过滤策略提升扫描命中率

开工前先聊两句我见过太多人用 FFUF、Dirsearch 扫目录跑完一条命令出几百上千条结果看着热闹最后真正能用的没几个。要么是默认字典太小漏了一大片要么是垃圾结果太多没法筛更常见的是压根没搞懂这两个工具扫出来的东西该怎么信。说白了会敲ffuf -w dict.txt -u http://target/FUZZ只是第一步核心难点在“怎么让字典对路”和“怎么把噪音滤掉”这两件事上。这篇东西不聊安装、不聊基础参数专门讲高级字典的构造逻辑、过滤规则的组合打法以及 FFUF 和 Dirsearch 这两个工具在实际对抗场景里怎么配合效率最高。适合那种已经跑过几天工具、但总感觉扫出来的结果不够干净不够深的朋友。内容都是我实际测试和复盘时攒下来的经验踩过的坑也会直接说照着改你至少能把误报率压下去一截。1. 字典策略决定扫描上限的那个变量1.1 为什么字典比工具本身更决定结果很多人在工具选型上纠结半天FFUF 和 Dirsearch 比来比去其实工具只是帮你发 HTTP 请求的框架能不能发现目标站点里藏着的后台、备份文件、接口真正起决定性作用的是你喂给它的字典。我举个实际例子。同一个目标站点用 Dirsearch 默认的db/dicc.txt大约 9 千多条跑一遍可能找到 20 个有效路径换成根据目标技术栈定制过的字典加上从 JS 文件里提取出来的路由词在差不多的时间内能找到 40 到 60 个有效路径。不是扫描器变聪明了而是你给的“问题列表”更贴题了。字典本质上就是一个词表词表覆盖得越准碰撞出真实资源路径的概率就越高。这里有个关键认知字典的选取逻辑取决于你手里有多少目标信息。对目标一无所知的时候优先用通用大字典知道目标技术栈比如 ThinkPHP、Spring、WordPress就要迅速切到专项字典然后逐步把自己生成的词条加进去。1.2 主流字典源与适用场景选型我平时案头常备几类字典按优先级排序是这样的通用小字典几百条到 2000 条像admin、backup、login、api、test、upload这种。跑得快适合第一轮快速摸底或者目标站点规模很小的时候用。通用大字典常见的有dirsearch自带的字典、SecLists/Discovery/Web-Content下的raft-large-directories.txt和raft-large-files.txt还有几万到几十万条规模的字典。适合对目标一无所知或目标文件特别多的情况。技术栈专项字典比如SecLists/Discovery/Web-Content/spring-boot.txt、nuclei的technologies相关字典、各类 CMS 的专用路径表。适合你已经通过指纹识别确定了目标用的框架和 CMS。敏感文件与备份字典.git、.svn、.env、*.bak、*.swp、vim缓存文件等这类字典往往体积不大但在实战里发现敏感信息暴露的效率极高。还有一个经验之谈接口路径字典和目录字典要分开用。现在的站点大量使用 RESTful 风格接口目录扫描器看的是路径层级但接口往往是/api/user/info这种没有目录含义的长路径。把这两类词条混在一个字典里请求数量大但命中率并不会同步提升还会增加被拦截的风险。所以我的习惯是目录扫一遍然后单独加载接口路径词表再扫一遍。1.3 根据技术栈与业务形态定制字典这个技巧很多人不会用但收益特别大。思路是这样首先确认目标的技术栈。这一步可以用浏览器插件、HTTP 响应头里的X-Powered-By、Cookie 特征、路由特征来做判断。比如确认目标是某个 Java 后台系统那么字典就该包含druid、swagger-ui、actuator、api-docs、jolokia这类路径。如果确认是 WordPress那就该上wp-content、wp-includes、xmlrpc.php这些。然后是业务形态。电商站点通常有cart、checkout、order、coupon、inventory一类的路径内容管理类站点更容易出现editor、upload、media、publish等词条企业内部系统则大概率存在hr、oa、report、attendance等业务缩写词。把自己带入开发者的视角想一想如果你来写这个系统路由会叫什么名字这个推演过程就是定制字典的核心方法论。操作上我会建一个custom.txt只要发现目标一丁点特征就往里追加词条。比如在首页源码里看到upload/js/立刻把upload、upload/img、upload/file、editor/upload这组词条写进去。这种方式产出的字典量不大但命中率奇高而且几乎不会引来告警。2. 过滤策略从海量噪音里捞出真金2.1 状态码过滤别只盯着 200初学工具的朋友都爱只看 200 状态码这个习惯得改。我见过不少站点把真实的管理后台入口做了重定向访问返回 301 跳转到登录页还有的站点所有不存在的路径都返回 200同时在响应体里输出统一的 404 页面内容。我实际测试过一个目标全站路径都返回 200但首页 HTML 里包含“页面不存在”的提示文案。如果你只看状态码所有请求全部被标记为可访问那这个扫描就废了。所以过滤的第一层一定要结合状态码和响应内容两套维度来判断。Dirsearch 里我常用--exclude-status404,403排除掉纯 404 和没有意义的 403同时加上--exclude-texts页面不存在,404 Not Found,File not found做内容层面排除。FFUF 里则是通过-fc 404,403排除状态码再用-fs按响应大小过滤。2.2 响应大小过滤最简单的降噪神器响应大小Content-Length是过滤垃圾结果时最锋利的刀。原理很简单目标站点的 404 页面长度是固定的比如某系统所有错误响应都返回 3KB 的提示页而真实存在的路径响应内容各不相同。那我们直接把等于 3KB 的响应全部过滤掉就行了。FFUF 的-fs 3000就是“筛掉响应大小刚好是 3000 字节的结果”。Dirsearch 对应的参数是--min-size和--max-size。但这个参数有个陷阱有些站点的 404 页面大小会动态变化比如带时间戳、带随机推荐内容这时候单纯按固定大小过滤就失灵了。我遇到这种情况会先手动请求一个肯定不存在的路径记住它的响应大小区间然后把-fs设为这个值。如果动态变化较大我会改成按大小范围过滤Dirsearch 里用--min-size4000 --max-size100这类反向思路表示只要小于 4000 和大于 100 的都排除不对需要重新想一下。实际操作里我更多用 FFUF 的-fs配合正则来组合处理。还有一个更省事的方法先不加过滤跑一遍只统计所有返回 200 的响应长度分布。正常情况下真实路径响应分布在各种长度垃圾响应对应的是某个或某几个极高频的长度值。我写了个小脚本统计结果凡是出现次数超过总请求数 10% 的单一响应长度直接判定为“模板页”在后续扫描里排除掉。这个思路比手工猜阈值强太多了。2.3 正则过滤与 404 特征建模稍微上点规模的目标站点不可能只用一条过滤规则。我打个比方有个目标站点全站使用统一模板任何不存在的路径都会返回 200 和一整页模板内容但模板里某个区域的提示文案会变化光看长度看不出规律。这时候就需要用正则过滤。FFUF 支持-fr参数后接正则表达式。比如ffuf -w dict.txt -u http://target/FUZZ -fr 页面不存在|error_404|not found凡是响应内容匹配到这个正则的一律丢弃。这个能力非常关键等于你给扫描器装了一个“语义过滤器”。再进阶一步是给目标做 404 特征建模。具体做法是先手动访问一个极其不可能存在的路径比如http://target/this_path_not_exist_12345。把返回的响应内容保存下来分析它的特征。特征可能是特定文案、固定长度、固定 HTTP 头也可能是状态码。把提取到的特征写进过滤规则里不管是 FFUF 还是 Dirsearch 都支持。有一回我测试某政府门户系统它的 404 页面返回的是 200 状态码正文里有一句特定案件编号提示语而且这句提示语在不同路径下会随机变化。这种情况下长度过滤完全失效我用正则匹配住了固定前缀才把真实的目录结构从几百条假阳性里捞出来。2.4 递归与爬取范围的控制逻辑还有一个容易被低估的过滤点递归扫描的深度控制。Dirsearch 的-r参数是递归扫描FFUF 是-recursion配合-recursion-depth。很多人把递归深度设到很大结果扫到第三层第四层时请求量指数级上涨响应里全是同一个 CMS 的模板噪声。我的习惯是前三层设置递归深度为 1 到 2且每一层都套用同样的过滤规则。更关键的是要在递归过程中动态把新发现的目录追加到字典里。比如第一层发现了admin/第二层递归就要把admin/login、admin/user、admin/config这些常见后台子路径加进去。这不算特别高级但很多人坚持不下来扫到一半看到结果太多就 CtrlC 了然后抱怨工具不给力。这个概念可以类比成整理房间。你手里有一张房间物品清单字典但真正要做的是先打开柜子发现目录再根据柜子里的分类继续找夹层里的东西递归动态加词。如果不控制范围每个柜子都全翻一遍时间全废掉了。3. 实战配置FFUF 与 Dirsearch 的参数组合技巧3.1 两个工具的核心差异与互补关系用了这么久这两个工具给我的感受是FFUF 是那种“给我一个 FUZZ 关键字我能撬动整个地球”的瑞士军刀灵活度极高Dirsearch 则更像一个开箱即用的专车司机装好就能跑字典、格式、递归这些都已经替你安排好了。要在实战里真正发挥它们的价值最好是让它们各干各的Dirsearch 负责广度。第一轮摸底快速摸出站点的目录结构、可能存在哪些类型的文件导出结果做初步研判。FFUF 负责深度。拿到 Dirsearch 的初步结果后针对已经确认的目录用定制字典做高精度的路径碰撞、参数枚举、虚拟主机发现。这个组合思路比只用其中一个要完整得多。我参与过的一次测试目标是一个典型的企业门户Dirsearch 在第一轮发现了upload/目录和几个api/路径但没深究。随后 FFUF 针对这两个目录结合技术栈字典做深度碰撞挖出了上传接口和一个未鉴权的配置读取接口。如果把这两个步骤反过来或者只用一种工具大概率会漏。3.2 输出格式与结果管理的隐藏参数很多人在扫完后处理结果的效率很低几百兆的扫描输出存成文本再用 Excel 手工筛痛苦不堪。实际上这两个工具都预留了结构化输出能力。FFUF 支持-o result.json和-of json输出每一项包含状态码、响应长度、URL 等字段。后续用jq做筛选非常方便jq .results[] | select(.status200 and .length1000) result.jsonDirsearch 也有--formatjson和-o参数。我常用的组合是让 Dirsearch 输出一份完整的 JSON再让 FFUF 的输出也带-o存下来这样后续做去重、深度分析、复盘汇报都很舒服不用重复扫描同一目标。再说一个对内部复盘特别有用的参数-saSkip target inspection。Dirsearch 每轮扫描前会检查目标是存活状态这个动作有些场景下会暴露扫描行为。用-sa跳过这个前置检查能让扫描直接开始速度上也有一点提升。FFUF 对应的思路是先批量确认一批目标存活再用-u逐个扫描避免反复探测。3.3 速率限制与随机延迟的经验值目标站点如果挂了 WAF 或访问频率限制扫描速度就必须克制。我的经验值是这样CDN 后面的站点可以尝试并发 40 到 80延迟设 0。CDN 本身能扛一定量的请求而且一般不会因为一个目录扫描就触发封禁。没有 CDN、源站直接暴露的小站点并发超过 20 就容易把服务打挂或者触发访问日志告警。这种场景建议并发 10 到 20配合 50ms 到 200ms 的随机延迟。明确知道对方有安全设备的站点速率必须低到接近人工浏览水平。并发 5延迟 1000ms 到 3000ms 随机配合随机 UA、随机 referer这是最保险的做法。Dirsearch 的并发控制参数用-t NUMFFUF 用-t NUM和-p DELAY。FFUF 的延迟参数支持按百分比波动比如-p 0.1-0.3实际效果是每次请求延迟在 100ms 到 300ms 之间波动比固定延迟更不容易被识别。如果你希望请求间隔更自然还可以把-p配合-rate一起用固定每秒最大请求数。4. 完整扫描流程一个典型站点的操作实录4.1 前期识别与响应建模实战中不要上来就扫。前戏做得越充分扫描命中率越高。我的标准流程是先用浏览器或简单 curl 探测目标拿到以下几项首页响应头看Server、X-Powered-By、Set-Cookie这些字段初步判断技术栈。单个明确不存在的路径记录 404 状态码、响应长度、响应正文特征。首页 HTML 源码快速扫一遍找 JS 文件路径、注释里可能暴露的内部路径、图片资源目录等。这套动作做完我对目标的“画像”基本也就出来了。比如一次测试某在线教育平台首页 HTML 里能找到/static/js/app.8f3a.js、/api/course/list、/admin/login这些字符串。这意味着什么意味着目标存在前端静态资源目录、RESTful API、独立后台入口。我直接把这些路径整理成种子字典。接下来模拟 404 特征。我访问了一个随机路径发现返回 200正文里包含“出错啦”三个字响应长度 2800 字节左右。后续扫描时凡是包含“出错啦”的响应全部用正则过滤掉。4.2 Dirsearch 第一轮宽口径扫描目标信息摸清后我先把 Dirsearch 开起来做广度摸底。命令如下dirsearch -u http://target -e php,jsp,json -t 30 --formatjson -o phase1.json --exclude-texts出错啦 --random-agent解释一下我的参数选择-e指定扩展名是为了匹配常见动态语言文件-t 30是控制并发目标没有明显防护所以敢放到 30--formatjson -o是保存结构化结果--exclude-texts出错啦是内容级过滤--random-agent是随机 UA避免默认 UA 被拉黑。这一轮跑了大约 6 分钟输出 1342 条请求过滤之后保留了 47 条“看起来有点意思”的路径。其中有/api/目录、/swagger-ui.html、/actuator/、几个静态资源目录。同时注意到有些目录返回 403403 不一定是坏事有时反而是“存在但禁止访问”的信号值得单独记录。4.3 FFUF 深度定向碰撞初步结果出来后我对/api/、/actuator/、/admin/这三个路径分别做 FFUF 深度碰撞ffuf -w api_common.txt -u http://target/api/FUZZ -fc 404 -fs 2800 -fr 出错啦 -t 20 -o phase2_api.json -of json这个字典api_common.txt是我从一个内部词库里改造来的包含v1、v2、user、info、list、upload、config、debug、test等常见 API 子路径。对/actuator/我用的又是另一套字典包含health、env、beans、mappings、metrics、heapdump这些 Spring Boot Actuator 的经典端点。结果在一分钟内就出现了/api/upload返回 200响应长度 1540 字节/actuator/heapdump返回 200长度 38MB。后者直接就是个大问题堆转储文件里通常包含数据库密码、密钥、会话信息。4.4 结果验证与去重扫描结果不是拿来就信得二次验证。比如状态码 200 但响应内容其实是登录页这种路径价值就很低。验证方法对每个候选路径记录响应长度、标题、内容特征词。用浏览器或 curl 逐一复核确认它确实是有效资源。把重复或同一页面不同入口的路径合并只保留唯一入口。敏感程度分级直接暴露的用户数据接口最高危其次是配置文件、日志文件、留存大量凭据的调试端点。我用脚本把两轮结果合并去重后剩下 19 个有效路径。其中有价值的包括 1 个上传接口、1 个未鉴权信息泄露接口、1 个备份文件、若干管理后台静态资源路径。整个过程总共耗时约 12 分钟。5. 常见问题与排查技巧实录5.1 为什么扫出来有大量假 200这个问题我遇到的概率极高根因通常是目标站点对不存在的路径统一返回 200 状态码。这类站点的 404 页面是模板化的正文固定或基本固定响应长度通常在某个窄区间。解决办法是给目标做一次“404 建模”把模板特征写进过滤规则里再重新扫。还有一类型是前端框架的路由模式比如单页应用SPA所有路径都会返回同一个index.html页面。这种站点用纯目录扫描基本没有意义应该切换到接口枚举或者做爬虫分析来获取真实路由。5.2 结果太少是不是漏了什么漏报的原因通常是这几个方向字典不够大或不够贴题扫描深度不够只扫了根目录没做递归扩展名覆盖不全目标存在 WAF某些请求被静默拦截了导致扫不到后面的路径。排查方法也很直接先手动请求一个已经被其他途径证实存在的路径看看扫描器能不能扫到。如果扫不到说明过滤规则或 WAF 把请求拦截了如果扫得到说明字典覆盖确实不足该去扩充词表了。另外很多站点的资源不在根目录而在/static/、/assets/、/public/下面如果字典里没有这些前缀漏报很正常。我通常会把这类高频目录前缀批量加到字典头部让扫描器优先碰撞它们。5.3 并发太高直接把自己的 IP 送进了封禁名单这种事我干过一次之后再也不头铁了。当时目标是个老旧的医院预约系统我图省事把并发拉到 60结果跑了不到两分钟后续所有请求全部返回 403紧接着我的出口 IP 被临时封了大概十分钟还连带影响到了其他目标的扫描节奏。经验就是如果目标是动态站点、后端有数据库查询、而且没有 CDN并发超过 30 就很危险。老系统尤其如此它们很多连线程安全都处理不好并发一高服务就宕机。安全测试的目的是发现问题而不是制造中断速率这块别逞强。封禁之后最尴尬的是你不知道封多久有些对象是小时级的有些是按天的遇到这种局面只能换入口或等解封工期白白浪费掉。5.4 响应大小过滤误伤真实文件-fs是按精准匹配过滤的但有些真实文件的长度会偶然性等同于 404 页面长度。比如站点的 404 模板是 2800 字节恰好某个真实目录的index.html也是 2800 字节就会被丢掉。怎么规避这种误伤我的办法是把“精准大小过滤”改成“范围过滤人工复核”。FFUF 虽然只支持-fs精确过滤但我可以在输出 JSON 后用脚本做二次筛选凡是长度等于 2800 的单独拉出来人工核对一遍而不是直接默认为假阳性。Dirsearch 的--min-size/--max-size设置成长度区间之后同样有这个问题建议在边界附近多留一点余量。5.5 扫描结果全被送去日志审计如何低调一点这个问题越来越现实。现在稍微正规一点的目标站点都上日志系统、态势感知平台目录扫描这种有明显特征的流量特别容易被揪出来。降低暴露面的方法优先使用低频扫描加随机延迟宁可慢一点也不抢时间。随机 User-Agent 必须安排必要时把 UA 伪装成常见搜索引擎爬虫。绝对不要用默认字典做高频请求默认字典的路径特征太明显安全设备一条规则就能匹配。对已确认的 CDN 节点可以优先尝试访问源站 IP源站的日志审计往往比 CDN 侧弱得多。扫描时尽量选择业务低峰期这样请求噪音更多更容易混过去。最后分享一个配合起来用的小技巧如果你手头目标不止一个别一个站点一个站点地跑。先把所有目标做一轮轻量级指纹识别按技术栈分组同一组的站点共用一套定制字典和过滤规则。这样字典不用反复造规则也能复用效率提升不是一点半点。我实际做过一次批量的目标梳理40 个站点分组之后扫描时间比逐个定制方案节省了大概一半。另外给新版 FFUF 用户提一句-ac参数自动校准能自动识别 404 响应特征并过滤掉对应内容。它通过先发几个随机请求生成基线再在扫描时把与基线相似的响应全部排除。这个参数对大多数模板化 404 的站点非常有效但要注意如果目标存在多种类型的 404 响应单基线校准未必覆盖全还是自己手动做特征建模更可靠。工具终归是工具真正值钱的是你用它的思路。把字典当子弹、过滤规则当准星FFUF 和 Dirsearch 才能打出真正的效果。