燕家猫从第一次在授权测试里手动猜目录猜到怀疑人生，到后来被同事按着头用SecLists，我才意识到自己之前绕了多大一圈。SecLists这个项目，本质上就是一群安全研究员把几十年踩坑积累下来的字典、规则、payload集中到一个仓库里，免费开源给你用。它能做什么？目录爆破、子域枚举、参数fuzz、密码字典生成、内容发现，几乎所有Web应用安全测试的前期信息收集环节，它都能给你一套现成的词表。这篇文章适合刚入门Web安全、准备参加CTF、或者正在给客户做授权渗透测试的朋友，我会从目录结构讲到实际使用姿势，再讲几个只有真用过才会注意到的坑。
1. 为什么"字典收集"是安全测试里最容易被低估的一环
1.1 从一次"无功而返"的目录扫描讲起
有一年我在做某个金融类Web应用的授权测试，目标是一个后台管理系统，登录页暴露在公网。常规思路是先扫目录，我那时候用的工具是dirsearch，默认词表也就几千条，跑了一个多小时，结果只扫出一个 /static/ 和一个 /favicon.ico。我当时以为是目标站点防护做得好，后来偶然翻到目标前端JS里有一个接口路径，手工访问直接返回了管理后台的静态资源目录列表。那一刻我才反应过来，不是目标安全，是我手里的字典太弱了。
那次之后我把SecLists完整拉下来，用其中的 Discovery/Web-Content/raft-large-directories.txt 重新扫了一遍，结果多出十多个隐藏路径，其中有一个备份文件目录直接暴露了源码压缩包。这不是个例，而是大多数扫描器自带字典的通病——样本量太小、覆盖场景太窄。SecLists的定位就是解决这个问题的，它把Web目录爆破、参数名枚举、子域名字典、密码字典、payload按场景拆好，你按需取用。
1.2 SecLists的出身与维护逻辑
SecLists是Daniel Miessler发起的开源项目，现在托管在GitHub上，仓库体量已经超过1GB。它不是一个简单的密码组合表，而是一个分类非常细的字典集合。维护者长期从真实渗透测试、漏洞披露报告、CTF赛题里提取关键词并归类，所以你会发现它的词表不是随机字符串，而是带着真实业务特征的词——比如 admin、backup、config.old、test、debug 这些路径，都是实际站点里出现频率极高的命名习惯。
了解这个出身背景很重要，因为决定了你该怎么用SecLists：它的每个子文件是为某一类具体任务准备的，用之前最好先确认自己要的是哪个场景，而不是对着一个上万行的文件盲目硬跑。
1.3 它和普通密码字典的核心区别
我经常看到有人把SecLists和那些"弱密码top100"混为一谈。实际上区别很大：
| 对比维度 | 普通弱密码字典 | SecLists |
|---|---|---|
| 覆盖场景 | 仅登录口令 | 目录、参数、子域、payload、用户名等 |
| 词条来源 | 常见弱口令 | 真实站点命名习惯、漏洞报告、CTF经验 |
| 更新频率 | 长期不更新 | 持续集成社区PR，定期更新 |
| 文件组织 | 单一文件 | 按Discovery/Passwords/Usernames等分目录 |
也就是说，SecLists不是一个文件，而是一个完整的字典体系。你可以在同一个任务里先用用户名列表做账户枚举，再用密码列表做口令测试，最后用目录字典收尾，整个流程都用它，这才是它真正的价值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 上手第一步：下载与目录结构解读
2.1 拉取仓库的两种方式
SecLists的获取方式很简单。第一种是直接git clone：
bash复制git clone https://github.com/danielmiessler/SecLists.git
注意这个仓库体积不小，如果网络一般可能等得比较久。我看到有人为了省时间只下载指定子目录，比如用 svn export 或者GitHub的目录下载工具，但我个人建议首次使用直接把全量仓库拉下来，原因很简单：你不知道当前任务下一秒会用到哪类字典，与其遇到再补，不如一次备齐。
第二种方式是到GitHub页面下载zip包。这种方式适合不打算长期更新的场景，但下次要用新词表就得重新下载，比较麻烦。如果你打算长期做Web安全测试，还是git clone方便维护，定期 git pull 就能同步新词表。
2.2 顶层目录树速览：真正高频的不是全部
SecLists完整拉下来之后，顶层目录看起来很多，但日常高频使用的其实集中在几个目录。我先给你一张速览表：
| 顶层目录 | 主要用途 | 使用频率 |
|---|---|---|
| Discovery/Web-Content | Web目录、文件爆破，最常用 | 极高 |
| Discovery/DNS | 子域名字典 | 高 |
| Passwords | 密码字典与组合规则 | 高 |
| Usernames | 用户名枚举 | 高 |
| Fuzzing | 参数名、SQL注入、XSS等payload | 高 |
| Miscellaneous | 杂项、特殊场景词表 | 中 |
| Payloads | 各类攻击payload合集 | 中 |
| IOCs | 入侵指标词表 | 低 |
每次有新手问我SecLists怎么用，我第一句话都是：别一上来就翻Payloads目录，你大概率用不上那些antivirus查杀规则的词条。先把Web-Content和Passwords两个目录吃透，覆盖80%的日常需求。剩下的等遇到具体场景再去翻，效率高得多。
2.3 体积权衡：什么时候全量，什么时候按需裁剪
SecLists全量仓库超过1GB，放在服务器上不占什么空间，但在某些云函数、CI/CD流水线或者容器镜像里，全量拉取会影响构建速度和部署体积。更合理的做法是在流水线里按任务类型裁剪，只复制需要的子目录。
比如你有一个自动化的子域枚举任务，只关心Discovery/DNS，那就没必要把Passwords和Payloads都带进去。我见过不少人在Dockerfile里直接 git clone SecLists，镜像凭空胖了几百MB，实际跑的时候只用了其中一个txt，完全是在为自己有限的带宽和存储添堵。
3. 高频实战场景：把SecLists用起来的几种姿势
3.1 目录与文件爆破：最经典也最见效
目录爆破是SecLists最经典的使用场景。我们常用ffuf或gobuster配合 Discovery/Web-Content/ 下的词表。以ffuf为例：
bash复制ffuf -u http://target.com/FUZZ -w /path/to/SecLists/Discovery/Web-Content/raft-large-directories.txt -mc 200,204,301,302,307,403 -t 50 -timeout 10
这里我习惯用 raft-large-directories.txt，因为它聚合了大量真实站点的目录命名习惯。比 directory-list-2.3-small.txt 那类纯字典覆盖率高很多。
跑完之后，重点不是看200状态码，而是留意301/302和403。403往往是目录存在但禁止访问的位置，有时候是权限限制，有时候是WAF拦了你的扫描特征，需要单独手工确认。301跳转则要多看Location头，判断跳转目标是否暴露了内网地址或内部路径。
经验是：目录爆破一定要结合文件后缀字典一起看。raft-large-files.txt 里有很多 ...bak、...old、...swp 这类备份文件，这些往往是敏感信息泄露的来源。扫描的时候别只扫目录不扫文件，配合使用价值翻倍。
3.2 子域名字典：DNS枚举的正确用法
子域枚举是信息收集阶段的高频动作。SecLists里 Discovery/DNS/subdomains-top1million-5000.txt 是一个很平衡的词表，5000条常见子域前缀，适合大多数目标。如果你想扫得更彻底，可以用 shuffle-dns 工具配合 subdomains-top1million-20000.txt 甚至更大的词表。
子域枚举推荐使用 puredns 或 shuffledns，它们会先做一次公共DNS解析验证，避免大量无效域名请求浪费资源。命令大致类似：
bash复制puredns bruteforce /path/to/SecLists/Discovery/DNS/subdomains-top1million-5000.txt target.com -r /path/to/resolvers.txt
如果你没有公共resolver列表，可以用系统自带DNS凑合，但成功率会低一些，因为很多权威DNS对高频请求有限制。这里的小技巧是：先跑5000条快速摸底，再针对主域名跑20000条做深挖。一次跑太多，可能不是被目标封IP，而是被上游DNS限速。
3.3 Web参数Fuzz：从参数名到参数值的延伸
不少人忽略了SecLists在参数枚举上的价值。现在的Web应用大量使用前端框架，接口路径往往藏在JS文件里，但参数名很多还是有迹可循的，比如 id、callback、redirect、debug、cmd、file 等。这些参数名的词条在 Discovery/Web-Content/burp-parameter-names.txt 里，跑接口参数枚举非常好用。
我在实际测试中遇到过这样的情况：一个接口正常传 id=1 返回正常数据，用SecLists的参数名字典跑出 debug=1 后，接口直接返回了堆栈信息，里面带着数据库查询语句。这种问题靠手工猜基本不可能发现，因为没人会想到一个正常业务接口里还有个debug开关。
参数级Fuzz也可以延伸到值域，比如文件读取类参数配合 Payloads/File 下的路径穿越词表。这块我的使用体会是：不要试图一条命令搞定所有事情，先把参数名枚举和值域枚举分开，分步验证，结果更可靠。
3.4 密码爆破与账户枚举：边界必须清楚
密码爆破是SecLists最"出名"的用途，也是合规风险最高的地方。Passwords/ 目录下有从Xato 10M密码列表中提取的 xato-net-10-million-passwords-1000.txt、10000.txt、100000.txt 等多个档位，还有 rockyou.txt.tar.gz 这个在CTF里出镜率最高的经典词表。
实际使用中要注意三点：
- 必须确保目标已授权。没有书面授权，任何口令测试行为都可能构成违规，这不是能力问题而是法律问题。
- 爆破速度要克制。默认工具配置可能每秒几十次请求，很容易触发目标风控、锁定账号，反而暴露自己。建议对单账号限制尝试次数，或者先用用户名枚举确定有效账户，再定向测试。
- 组合策略优于单一字典。单纯用rockyou字典碰到强密码概率极低，SecLists里
Passwords/Common_Credentials下的组合词表更适合真实场景。
对于账户枚举，Usernames/ 目录下有常见英文名、中文拼音、admin类账号等词表。在登录接口观察返回差异，比如"用户名不存在"和"密码错误"的不同提示，是判断账户是否存在的经典方法。我一般先把这步做完，确定有效账户后再做密码测试，效率远高于盲目爆破。
4. 效率问题：几万条规则不会用等于没用
4.1 按目标场景裁剪字典
SecLists的词表很大，但直接拿全量词表跑往往会遇到两个问题：时间太长、准确率太低。比如 raft-large-directories.txt 有近5万行，带着全量跑一个中小型站点可能要几个小时，其中大部分路径对目标站点毫无意义。
更聪明的做法是基于目标特征做裁剪。比如目标是政务类网站，优先用目录里的 Chinese 相关词条；目标是PHP站点，就重点看 .php、.bak 这类后缀词条；目标是Java站点，多关注 /WEB-INF/、/actuator/ 这类路径。SecLists的目录设计已经把基础分类做好了，你只需要多花几分钟挑对词表，就能省下几小时的扫描时间。
4.2 去重、清洗与格式化：Linux命令行三件套
不同词表之间经常有重复条目，直接拼接使用会造成无效请求增多，甚至触发WAF。我一般会做一次简单的清洗：
bash复制cat file1.txt file2.txt | sort -u > merged.txt
sort -u可以排重，但如果需要保留原始顺序，可以用awk：
bash复制awk '!seen[$0]++' file1.txt file2.txt > merged_dedup.txt
另外还要注意Windows和Linux的换行符差异。你在Windows下编辑过词表再传到Linux用，每行末尾可能带着 \r，这会导致请求路径变成 /admin\r，服务端自然返回404。安全的做法是用 dos2unix 统一格式，或者用sed删掉 \r：
bash复制sed -i 's/\r$//' merged.txt
这个坑我踩过不止一次，每次都是在扫描结果里看到大量404才反应过来。
4.3 组合词规则：追加目标基本信息
SecLists自带的字典再全，也不会包含目标站点的品牌名、系统名、员工花名这类特有信息。实际测试中，这类信息才是真正容易命中弱口令的突破口。我在做口令测试前，会把收集到的目标信息追加进密码字典，比如：
- 品牌名+年份：
brand2023、brand2024 - 品牌名+特殊字符：
brand@123、Brand#2024 - 拼音全拼+手机尾号：
zhangsan123、lisi@521
把这些词加到字典末尾，往往比穷举万能密码更有效。SecLists里 Passwords/Common_Credentials 下面有类似结构的组合词表，可以直接参考它的生成逻辑做自定义扩展。
4.4 工具对字典格式的细节差异
不同工具对字典内容的解析方式不同。比如 wpscan 的 --passwords 参数要求字典每行一个密码，不能有空行，否则会报错；hydra 在读取用户名和密码字典时对冒号、空格的处理也不一样，如果字典里有注释行或空行，可能导致任务中断。
这里我的建议是：每次换一个新工具，先用一个100行的小样本测试字典格式，确认工具能正确读取再跑全量，避免跑了大半才发现口令解析错位、结果全废。这个小习惯帮我省下过不少重跑的时间。
5. 常见问题与踩坑记录
5.1 路径变化：老教程里的路径可能已经失效
SecLists在不断调整目录结构，网上很多老教程给出的路径现在已经不对了。比如以前 Discovery/Web_Content 用的下划线，后来改成了 Discovery/Web-Content；一些文件名也在合并、移动。遇到路径不存在的情况，先去仓库的GitHub页面确认最新目录结构，或者直接搜索文件名定位。
我自己的习惯是在拉取最新仓库后，用find命令扫一遍高频文件名，确认路径：
bash复制find /path/to/SecLists -name "raft-large-directories.txt" -o -name "rockyou.txt*"
这样能快速定位实际路径，避免照抄老命令时一路404。
5.2 超大文件造成的内存问题
有一些词表非常大，比如 rockyou.txt 解压后有14GB左右，直接用某些工具读取可能内存暴涨。实际使用前最好先 head -n 1000 rockyou.txt 看下词条格式，然后按需切割小份使用。如果确实需要全量，选择支持流式读取的工具，避免一次性载入内存。
另外大文件的编码也可能是个坑，某些词表包含特殊字符，在终端里看起来很乱，不影响工具读取，但如果要手工编辑就很容易出错。
5.3 Windows下的换行符与路径分隔符问题
Windows下使用SecLists主要遇到两个问题：换行符和路径分隔符。前面说过换行符会导致请求404，路径分隔符则影响命令行解析。在PowerShell里执行ffuf时，路径里的反斜杠可能被转义，建议统一用WSL或者在命令里改成正斜杠：
powershell复制ffuf -u http://target.com/FUZZ -w C:/Tools/SecLists/Discovery/Web-Content/raft-large-directories.txt
如果你用WSL，挂在/mnt/c下面的路径也可以直接用，但要注意工具处理Linux路径和Windows路径的差异。我的建议是安全检查类的工作直接在Linux虚拟机或WSL里做，省掉一大半兼容问题。
5.4 关于授权与合规的提醒
SecLists本身是一堆文本文件，它不会自己去攻击任何系统，真正决定行为边界的是使用它的人。我在行业内见过不少新手拿到字典就对着公网IP一顿猛扫，这种做法极其危险。没有任何授权的情况下，哪怕只是发一个目录请求，也可能被判定为未授权扫描，给自己带来麻烦。
我的经验是：所有用SecLists开展的测试活动，必须有明确的授权范围，最好有书面合同或授权书，明确允许测试的域名、IP段、时间段和测试方式。遇到客户，先确认授权范围，宁可多问一句也不要做越界的事情。这个原则不是套话，是真的能保护你自己的职业发展。
重要提示：SecLists只是一本"词典"，使用它之前，请确保你拥有对目标系统的合法测试权限。授权边界问题不是技术水平问题，而是职业底线问题。
6. 几个值得关注但容易被忽略的子目录
6.1 Miscellanous：看似鸡肋，实则有大用途
Miscellaneous 目录在SecLists里属于"什么都有一点"的地方，但里面的 misc-user-agents 对绕过简单UA检测很有用。有些WAF会拦截默认扫描器的User-Agent，你用过数据库里的随机UA列表替换默认UA，能降低被封概率。还有个场景是接口返回内容检测：有些站点会拦截带明显扫描特征的请求头，这时候把UA改成浏览器UA就过去了。
实操中我会单独抽几个高频UA存成独立文件，方便ffuf和Burp Suite的Intruder直接调用：
bash复制head -200 /path/to/SecLists/Miscellaneous/misc-user-agents.txt | tee /tmp/ua_top200.txt
6.2 IOCs：不是平常项目能用到，但应急响应时很关键
IOCs 目录收集了不少恶意IP、域名、文件哈希等指标，主要用在应急响应和威胁情报场景。如果你在做安全运营、流量分析，可以用这些词表去对内部日志，发现内部机器是否访问过已知恶意地址。这块平常确实用不到，但一旦遇到真实的安全事件，手边有现成的情报词表会从容很多。
6.3 SecLists和Burp Suite、ffuf的整合思路
SecLists与Burp Suite的整合非常简单。Burp的Intruder支持直接加载字典文件，你把SecLists里的词表路径填进去，选中爆破位置即可。我习惯在Intruder的Payload Options里加载 raft-large-directories.txt 跑目录，加载 xato-net-10-million-passwords-1000.txt 跑登录接口，加载 burp-parameter-names.txt 跑参数枚举。
ffuf与SecLists的结合更紧密，因为ffuf是命令行工具，天然适合批量操作和脚本化。把不同场景的词表路径维护在脚本变量里，需要时一行命令切换，整体的测试效率会明显提升。这套工作流稳定下来之后，新项目来了基本就是先跑一遍SecLists相关命令，再进行手工验证，大大减少了信息收集阶段的时间消耗。
7. 我的使用习惯与最终建议
说了这么多，最后分享几个我自己沉淀下来的使用习惯。
第一，SecLists不是一次安装就完事的东西。它的价值在于持续更新，我会每隔几周 git pull 一次，把社区新增的词条同步进来。新词条往往来自最新漏洞报告和真实测试案例，含金量比老词表高。
第二，不要被词表数量绑架。很多人下载了SecLists就觉得自己"有了武器库"，实际跑起来发现只用了其中两个文件。我的建议是先把最常跑的8-10个文件记熟，包括路径和适用场景，再去探索冷门词表，一步步扩大自己的熟悉区域。
第三，词表只是起点，真正的判断力来自手工验证。扫描器会给你一堆结果，但哪些路径值得深挖、哪些参数值得测试、哪些报错信息暗示了后端逻辑，这些都要靠你自己去分析和确认。SecLists帮你省下的是时间，而不是替你思考。
回到文章开头那个故事，现在我做Web应用测试，第一步就是用SecLists铺开信息收集，但心态完全不一样了——它变成了一把顺手的手术刀，而不是一台无脑的挖掘机。希望这篇教程能帮你省下我曾经浪费过的时间，少走几段弯路。