★ FEATURED ARTICLE 简介在Web安全测试与渗透测试中路径发现是资产梳理与攻击面摸排的关键环节。目录扫描依赖高质量的fuzz字典但字典的价值并不在于词条数量而在于分层结构与场景匹配。本文从路径发现的基础概念出发讲解如何按目标类型静态站、API服务、后台管理选用合适的字典详细介绍ffuf与dirsearch的参数配置、结果判读方法并针对高频问题给出避坑建议。同时通过脚本对字典进行去噪、瘦身与交叉验证帮助安全从业者提升路径扫描的准确率与效率建立可持续维护的字典知识库。1. fuzz字典不是堆词量先想清楚“全”是给谁用的拿到一份号称“史上最齐全”的web fuzz字典第一反应往往是直接扔进dirsearch跑一遍。实际跑完会发现扫出来的东西很多真正能用上的很少——不是字典不行而是没搞清楚这份字典的边界。fuzz字典解决的是“路径发现”问题它的价值不在词条总数而在覆盖结构和场景匹配度。静态站、API服务、后台管理、云存储桶这四类目标需要的字典完全不是一回事。这篇笔记就把这套字典的选型逻辑、接入工具链的参数配置、以及我踩过的几个典型坑讲清楚适合正在做授权测试或路径梳理的从业者参考。2. 字典背后有逻辑按目标类型做分层选型比盲目跑完更值2.1 为什么默认字典总是“看起来全、扫不深”很多下载下来的字典体积不小但词条构成很混乱常见路径、备份文件、参数名、Tomcat管理路径、云厂商存储桶前缀混在一起一把梭跑下来噪点极高。这套fuzz字典的合理之处在于它按用途做了目录分层而不是单一一个大文件。我一般会把字典分成四层来看路径层/admin、/api、/v1、/.git、/backup 这类目录发现用文件名层index.php.bak、config.php.swp、web.config、.env 这类敏感文件发现用参数层id、page、file、redirect、url 这类参数名爆破用扩展名层.php、.jsp、.asp、.json、.xml 这类配合路径做组合探测判断一套字典健不健康先看它是否做了这种分层。如果只有一个几千行的txt从头扫到尾大概率会淹没在404响应里。工具层面的常见做法是分层扫描先用路径层做粗筛再用文件名层针对敏感区域做细扫这样命中率比一把梭高很多。2.2 按目标类型选字典静态站、API服务、后台管理选字典不能只看目标是不是一个“网站”要看它的技术形态。纯静态站用带大量动态路径后缀的字典就是浪费时间API服务需要的不是路径而是资源名和版本号。静态站 / 文档站优先用文件名层字典重点找 .bak、.old、~ 结尾的编辑器残留文件。这类站点目录结构简单但历史遗留文件往往藏在线文档路径里。API 服务重点关注 /api/v1/users、/api/swagger-ui.html、/actuator、/graphql 这类路径。动词型路径/getUserInfo在这个场景下的意义不大真正有用的是资源型路径加 HTTP 方法组合。后台管理类/admin、/manage、/system、/console、/debug 这类路径要单独跑并且配合低频率、高延迟的参数设置避免直接把登录接口打崩。云存储场景/bucket-name、.s3.amazonaws.com 前缀、OSS 域名探测这类词普通目录字典里覆盖不到需要单独追加。所以拿到这套字典后的第一件事不是直接跑而是先看清楚它的目录结构把场景对应的字典挑出来。命令层面可以用 find 快速浏览find /path/to/fuzz-dict -maxdepth 2 -type f -name *.txt | sort这段命令把字典目录下两层内的所有 .txt 文件列出来并排序用来确认字典文件的分层是否符合预期。常见的做法是路径类字典文件命名通常包含 path、dir、directory 关键字文件类包含 file、backup、sensitive参数类包含 param、query。如果排序后发现这些文件确实分开了这套字典的底子是好的如果全挤在一个文件里说明需要自己做一次拆分。2.3 字典里藏着“环境标记”怎么识别一套字典的健康度字典文件本身也能透露出很多信息。值得看的三个维度换行符、词条长短分布、是否带注释。Linux 下用 file 命令能快速判断编码CRLF 换行的字典在一些严格解析参数的工具里会有坑比如 Wfuzz 对结尾的 \r 处理就经常出问题。这时候要先转成 LFsed -i s/\r$// /path/to/dict/*.txt词条长短分布决定了扫描效率全是十几个字符的长路径会让扫描队列拉长全是短路径又容易产生大量无效请求。我一般会看一下最长和最短路径awk { print length, $0 } /path/to/dict/sensitive-files.txt | sort -n | tail -20这条命令按词条长度排序打印最长的20条。如果出现类似 .git/config 这种本身就是完整路径的词条说明这份字典混合了路径和文件命名需要拆开。带注释的字典要重点看注释往往标明这份字典适用的中间件版本或场景比如某些词条只对旧版中间件有效在新版本上就是纯噪声。3. 把字典接入工具链ffuf 与 dirsearch 的参数配法和结果判读3.1 把字典喂给 ffuf基础命令与过滤器的意义ffuf 是目前路径发现场景里用得比较顺手的工具它的核心优势是支持多字典组合和多条件过滤。先看最基础的目录扫描命令ffuf -u http://target.com/FUZZ -w /path/to/fuzz-dict/path-layer.txt \ -mc 200,301,302,403,500 \ -fc 404 -fs 12345 -t 50 -rate 100-u 指定目标URLFUZZ是占位符字典里的每个词条都会替换到这个位置-w 指定字典文件-mc 是匹配的响应码白名单200和301最常用403也要留因为有时候路径存在但被权限拦截-fc 404 直接过滤掉404响应-fs 过滤掉特定响应大小这个参数很关键很多站点对不存在的路径统一返回一个固定大小的404页面过滤掉它能少看一大堆垃圾结果。线程和速率要看目标承受能力我一般先用 -rate 100 做试探稳定后再慢慢往上加。跑完之后拿到的是命中路径列表。这时候要做的不是看200的路径而是先看301和403——301跳转说明路径存在但可能指向另一个域名或带后缀的路径需要跟进403在不少场景下比200更有价值因为它往往表示路径存在但禁止访问。ffuf 支持递归扫描常见做法是加 -recursion 参数遇到目录类型命中后自动往下一层跑。但递归深度要控制建议 -recursion-depth 2太深会把请求量放大好几倍得不偿失。3.2 dirsearch 做快速分层配置项怎么调dirsearch 是另一套顺手的工具和 ffuf 的思路不太一样它是目录扫描专用内置了很多默认字典和扩展名逻辑。我一般会用它对目标做第一轮快速梳理再用 ffuf 做精细验证。dirsearch 的关键参数如下dirsearch -u http://target.com -e php,jsp,json -x 404,403 \ -t 30 --random-agent --exclude-status500,502-e 指定要追加的扩展名列表跑一遍相当于把同一条路径用不同扩展名各探测一次-x 排除不想看的响应码--random-agent 随机化 User-Agent避免字典刚跑几十条就被日志特征拦掉--exclude-status 把服务端错误排除500、502这类响应在路径扫描里没有太多参考价值可能是程序异常不一定是路径存在。dirsearch 跑完会输出一个报告文件里面按响应码归档了所有命中项。我一般只看 200、301 和 403 三个分类。403 的路径需要人工确认如果字典里跑出来一个 /admin 返回 403而目标站点本身用的是另一个管理路径那这个结果的价值有限如果目标站根本没有 /admin那这个 403 很有可能是服务端对不存在路径做了统一拦截属于干扰项。3.3 结果判读响应码相同不代表路径真实存在这是最容易翻车的一环。很多站点的 404 和真实路径的 200 页面大小完全一样或者所有不存在的路径都返回 200 再在页面里写“未找到”。这时候只看响应码完全不够得结合响应体和响应时间。curl -s -o /dev/null -w code: %{http_code}, size: %{size_download}, time: %{time_total}\n \ http://target.com/nonexistent-path-12345先手动探测一个大概率不存在的随机路径记录下它的响应码、页面大小和响应时间作为基线。再去和字典命中的路径比对如果命中路径的 size 和基线完全一致哪怕响应码是 200 也要标记为疑似误报。响应时间也是一个辅助指标存在路径通常会在服务端做逻辑处理响应时间会略长不存在路径往往是快速返回统一错误页。把这些数据记下来后面第 5 章讲去噪脚本时会用上。4. fuzz 字典实战避坑四个高发翻车现场与排查记录4.1 现象字典一跑就被封 IP日志里全是超时原因字典里混合了太多高权重路径词条加上线程开得大目标服务端在短时间内收到了超量的请求触发了频率限制。这类问题在带了 login、api 等接口词汇的字典里尤其明显。解决压缩线程数同时引入随机延迟。ffuf 里的做法是加 -p 0.1-0.3 让每个请求之间随机停顿 100 到 300 毫秒。更体面的做法是先做一次小样本探测用 30 个词条跑一遍观察响应时间的变化斜率。如果延迟持续爬升说明服务端已经在限流边缘了这时候要降速率而不是换字典。我一般把 -rate 控制在 50 到 80 之间除非目标是纯静态站。4.2 现象结果里全是 200但每个页面内容都相同原因目标用了前端渲染框架服务端对所有未匹配路由统一返回同一个 index.html 页面响应码 200。这类站点用路径字典去扫命中率几乎为零因为路由表在客户端 JS 里。解决切换思路不再用字典扫描路径改成先抓取页面的 JS 文件列表再提取 JS 里定义的路由字符串。常见做法是用子域名枚举加上 JS 内容分析而不是继续堆字典词条。字典在这种场景下的价值只有配合真实路径前缀才成立比如已知有个 /app 路由再往下面叠加字典词条做二级路径爆破。4.3 现象接口路径扫出来了但参数爆破结果全是空原因字典里的参数层词条来自通用场景比如 id、page、name这些在 REST 风格接口里并不适用。REST 接口的参数通常是路径参数嵌套在 URL 路径段里而不是 query 字符串。比如 /api/v1/user/123你的字典是 /api/v1/user?id 的格式完全对不上。解决针对接口场景先抓包看真实请求格式再决定要不要跑参数爆破。常见做法是先用路径字典扫出 /api/v1/user 这个资源点再手测几组参数组合确认参数传输方式是 query 还是 path然后再写自己的参数词条文件。通用参数字典在这种场景只是辅助真正有价值的是从历史请求里提取真实参数名。4.4 现象字典文件在 Windows 下生成的跑起来报错或内容错乱原因换行符问题。Windows 下的 CRLF 换行在部分工具里会导致词条末尾带 \r扫描结果里会出现带隐藏字符的路径请求发出去后服务端返回 302 或 400但又查不出原因。解决用第 2.3 节里的 sed 命令做一次全局替换把 CRLF 转成 LF。转完之后再用 head -n 5 抽查几行确认词条格式干净。这类问题很隐蔽表现出来就是“随机有几个路径明明存在却扫不到”很多时候不是字典词条不够而是格式污染导致请求路径不合法。5. 提升命中率的字典工程去噪、瘦身与覆盖验证5.1 用脚本去掉高概率 404 噪声词条字典用久了会发现有些词条在几乎任何站点上都不存在比如 /path_that_never_exists、/test_xyz 这类占位词条。它们存在的意义是早期的格式调试在正式扫描里就是纯噪声。可以用脚本和响应大小做一次清洗。思路是先采集基线响应大小再用脚本过滤掉那些只产生基线大小的词条。脚本如下import requests import sys target sys.argv[1] dict_file sys.argv[2] baseline_size int(sys.argv[3]) output_file sys.argv[4] with open(dict_file, r, errorsignore) as f: words [line.strip() for line in f if line.strip()] clean_words [] for word in words: url target.rstrip(/) / word try: resp requests.get(url, timeout5, headers{User-Agent: Mozilla/5.0}) if resp.status_code ! 404 and len(resp.content) ! baseline_size: clean_words.append(word) except requests.RequestException: continue with open(output_file, w) as f: f.write(\n.join(clean_words)) print(fraw: {len(words)}, cleaned: {len(clean_words)})这个脚本会逐个请求字典里的词条把返回 404 或响应大小等于基线值的词条过滤掉剩下的写入新文件。第一次跑完你会看到清洗前后数量差距非常大尤其是那些从别的字典里合并过来的词条。清洗前的准备步骤很重要先手动请求一个不存在的路径拿到 baseline_size再用第 3.3 节的 curl 方法确认这个 size 在多次请求下是稳定的。如果目标有负载均衡不同节点返回的 404 页面大小可能不同这时候要把 baseline 设成区间而不是单一值脚本也要相应改成abs(len(resp.content) - baseline_size) threshold这种写法。5.2 按响应码做二次筛选生成场景子字典第一次清洗完成之后字典的体积会小很多但还不够精致。接下来按响应码把词条归成“确定存在”“疑似存在”“被拦截”三类。这个阶段不需要再发请求直接消费上一次扫描的应答记录即可。常见做法是让 ffuf 输出 JSON 格式的结果文件再用脚本处理ffuf -u http://target.com/FUZZ -w cleaned-dict.txt \ -mc 200,301,403 -o result.json -of json然后写一个简短的分析脚本按状态码统计词条import json from collections import defaultdict with open(result.json) as f: data json.load(f) groups defaultdict(list) for item in data[results]: groups[item[status]].append(item[input][FUZZ]) for status, words in groups.items(): filename fdict_status_{status}.txt with open(filename, w) as f: f.write(\n.join(sorted(set(words)))) print(fstatus {status}: {len(words)} words - {filename})这样做的好处是后续再碰到同类目标时可以直接按响应码选用对应字典。我之前对某跨平台系统的后台做了两轮扫描第一次用了混合字典跑了很长时间回头用这份“按状态码归档”后的 403 和 301 字典复扫结果近一半的有效路径在首轮被混在噪声里没细看。5.3 用核心词库交叉验证覆盖完整性字典清洗到一定程度后要回答一个核心问题该有的路径覆盖到了没有交叉验证的办法是准备一个小而精的核心词库包含一定数量在同类目标上必然存在的路径比如 /robots.txt、/favicon.ico、/.well-known/security.txt、/sitemap.xml。先用核心词库跑一遍目标确认工具链和字典都能正常命中再换大字典最后对比两次结果的差异。差异部分需要人工确认如果大字典跑出来的结果没有包含核心词库的命中项说明大字典被过度清洗了或者过滤条件写得太严格把真实路径也滤掉了。另外交叉验证还有一个附加价值能帮你判断目标站点的路径风格。比如核心词库里有个词条在 A 站返回 200、在 B 站返回 302、在 C 站返回 404这本身就是一种信息——不同站点的路径处理逻辑不同后续选字典时可以根据这个特征做倾向性调整。6. 把字典变成自己的知识库版本管理与增量更新习惯字典不是下下来就完事了它需要持续维护才能真正变成自己的东西。我现在的做法是保留原始压缩包单独建一个 working 目录做日常使用任何清洗和分类都在 working 里完成不动原始文件。配合 git 做版本管理每次往字典里加词条都留一条提交记录。这样做的价值在于当某次扫描出现奇怪结果时能通过 git diff 回看最近改了什么。增量更新的主要来源有三个一是授权测试中真实出现的路径每次都记录到一个“新词”文件里二是阅读历史报告把高价值路径摘出来三是看目标响应特征比如返回 403 的路径往往结构相似这些规律适合手工归纳成模式词条。这套字典用顺手之后扫描的命中率会有明显提升——因为它的词条都是经过真实场景检验的而不是单纯堆量。从那以后我每次拿到一份新字典都会强制走一遍“分层、清洗、交叉验证、归档”这套流程虽然前期多花一点时间但后面每次扫描都能省回好几倍时间希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
