企业官网建设流程全解析

简介：这是一份面向渗透测试与安全评估人员的字典合集，覆盖框架信息泄露、备份文件泄露、配置文件泄露等常见信息收集场景。按用途划分目录：dir目录字典可直接加载Burp Suite进行目录爆破；dns子域名字典辅助域名收集；filename备份文件名字典支持文件名与后缀组合访问；另有弱口令密码字典和用户名字典，适合在授权测试中快速验证常见凭据。

资源共204个文件，压缩包32.48MB。除大量txt字典（171个）外，还包含13个Python脚本、6个Markdown说明文档、3个CSV默认密码表、3个Excel表格，以及alldorksv3、routes、dic、jar、license、json、lst等特殊格式文件，兼顾规则模板、辅助脚本与参考数据，便于不同工具链调用。目前已有51人学习下载，对于需要快速搭建目录爆破、子域枚举和弱口令测试工作流的人员，这一字典包能减少收集与整理成本，直接投入授权测试，适合Web安全初学者和中级渗透测试者按需取用。

1. 渗透字典，决定信息泄露测试上限的那批文本

一份渗透字典的质量，往往比扫描器版本更决定结果。测试 Spring Boot、若依这类框架时尤其明显：框架路径、备份文件、配置文件泄露，靠的不是扫描器多聪明，而是字典里有没有对应的路径和文件名。这个压缩包表面看是常见渗透字典集合，拆开后会发现它把目录、子域名、备份文件名、弱口令、用户名五类 payload 分开摆放，还带 alldorksv3、PASS.JAR、credentials.json 这类附加料，明显是按真实授权测试流程整理的。适合准备做内网或外网授权测试、需要快速搭一套 Burp 探测物料的人，也适合照着它的分类思路自建一份信息泄露语料。下面的内容不吹“字典越大越好”，而是从框架信息泄露、备份文件组合模式、配置文件泄露三个具体场景，把用法、参数和踩坑一次讲掉。

2. 拆开这包字典：先搞清楚每个文件是干什么的

拿到压缩包不要急着整包丢进 Burp，先把文件过一遍。很多人只盯着 password 字典用，结果在框架信息泄露测试时浪费了大量时间，因为真正能用上的其实是 dir、filename 这两类词表。

2.1 dir、dns、filename、password、username：五类字典的设计意图

从摘要可以明确这套字典的五大分类：dir 为目录字典，dns 为子域名字典，filename 为备份文件名字典，password 为弱口令字典，username 为用户名字典。用表格整理一下使用场景：

dir 字典是整套的基座。很多框架信息泄露路径，比如/.git/HEAD、/actuator/、/WEB-INF/classes/，都是一行一行扫出来的，没有这些基础路径，后面组合模式无米下锅。dns 字典则适合先做子域名收集，锁定目标暴露面后再进入目录爆破阶段。

filename 字典是这套资源里比较有价值的部分。它放的不是完整路径，而是纯文件名，比如www、backup、admin、1、index这类常见命名。摘要里特别提到“使用组合模式，将文件名与后缀进行组合访问”，也就是说，扫描时要用文件名加后缀的方式请求，例如www.zip、www.sql、backup.tar.gz。这个设计比硬编码完整路径的字典灵活得多，尤其在遇到不同站点备份命名习惯不一致的时候。

password 和 username 字典不用多说，区别在于它已经按用途拆好。weak password 和 username 分开，意味着可以在 Burp Cluster bomb 模式下做交叉组合，避免把所有口令都堆在同一个文件里导致 payload 爆炸。

2.2 容易被忽略的 CSV、JAR 和 JSON：附加文件的价值

压缩包里除了那五类核心字典，还躺着一批看着像其它东西的文件。先看 alldorksv3，这是典型的 dork 列表，可以导入 Burp 测试一些搜索型接口或跟踪链接类功能，也可以在收集信息阶段用来查公开索引。它不是用来直接跑目录的，这点要分清。

passwords.csv、Scada_Password.csv、ics-default-passwords.csv三个文件是口令表。后两者面向工业控制系统，比如常见的施耐德、西门子、罗克韦尔设备默认账号。如果你测试的是能源、制造行业的授权目标，这两份表会命中很多通用默认口令；但如果测的是互联网业务系统，命中率会很低，绕开就行。

table.dic是通用字典，通常用来兜底。前面 dir 字典没扫出来的路径，可以用它再扫一遍，代价是时间翻倍。PASS.JAR这个文件名很有迷惑性，它不是 Java 可执行包，本质是一份按场景整理的口令字典。遇到这种命名别直接当压缩包处理，先用file或编辑器查看头部，再决定怎么加载。credentials.json是结构化凭证文件，适合给脚本读取，比如自动化登录接口测试时直接解析成用户名密码对。

6captchas.lst是验证码相关列表。可能是验证码接口路径，也可能是常见验证码参数名。在登录爆破遇到图形验证码时，把这个列表配合手工验证，可以先尝试绕过或寻找重复使用验证码的接口。还是那句话，授权范围内再测验证码逻辑，别拿它去打没有授权的目标。

2.3 框架指纹与配置泄露：这些路径到底从哪里来

光有字典还不够，得知道扫什么路径。以目前最常遇到的 Spring Boot 框架为例：/actuator、/actuator/env、/actuator/heapdump、/trace、/mappings、/beans，这些端点是 Spring Boot Actuator 的一部分，一旦暴露，经常直接泄露环境变量、数据库连接串和堆内存快照。对应的就是 dir 字典里的 actuator 相关条目。

若依框架是另一类高频目标。它基于 Spring Boot 二次开发，常见路径包括/prod-api/、/dev-api/、/api/、/druid/、/swagger-ui.html、/tool/gen等。框架默认路径的泄露往往意味着配置文件也会被顺带找出来，比如application.yml、bootstrap.yml、logback.xml。

配置文件泄露是信息泄露里最要命的一块。Maven 项目会把settings.xml放在本地仓库或者 CI 机器上，如果 Web 目录存在备份文件把它打包进去，攻击者拿到后能直接看到私服地址、账号密码。logback.xml是日志配置文件，泄露后通常会暴露日志路径、日志级别、常见业务包名，甚至某些硬编码在<property>里的密钥。这套字典里的 filename 列表恰好覆盖了这类常见文件名，扫描时把logback.xml、application.yml、settings.xml当作普通文件名去试，命中率比想象中高。

3. 把字典加载到 Burp：Intruder 配置与资源池调优

字典最后都要落到扫描工具上。Burp 是渗透测试里最常用的载体，这里从 Intruder 四种模式开始，讲清楚怎么把这套字典挂上并让扫描不翻车。

3.1 Intruder 四种攻击模式怎么选

Burp Intruder 有四种模式，很多人第一次用就选 Cluster bomb，结果请求数量呈指数级增长，跑了一半就卡死。结合这套字典，我的建议是这样：

• Sniper（狙击手）：一个 payload 位置遍历同一字典。适合测试单个参数或单个路径。比如把GET /{这里替换} HTTP/1.1中的路径位置设为唯一插入点，加载 dir 字典。
• Battering ram（撞锤）：多个位置共用同一个 payload。适合把用户名和密码位置同时填同一个值。
• Pitchfork（草叉）：多个 payload 列表按行平行使用。username 字典和 password 字典如果行数一致，可以一一对应尝试，减少组合数量。
• Cluster bomb（集束炸弹）：多个字典做笛卡尔积。适合 filename 组合模式，一个位置放文件名，另一个位置放后缀，但它们组合后会生成大量请求，建议先把文件名列表控制在 100 行以内。

一般拿到这套字典后，第一步扫描目录用 Sniper 就够了。Sniper 对字典没有尺寸要求，即使 filename 字典有几千行，也能跑完。如果确实想让结果更可控，可以把普通路径和备份文件名合并成一个整合文件，再用 Sniper 跑一遍。

3.2 Payload 处理与 Grep-Match 设置

在 Burp 里加载字典的流程很固定：进入 Proxy 或 Repeater，发送请求到 Intruder，然后在 Payloads 选项卡里选择“Simple list”，点击 Load... 选择字典文件。这里有三个细节很容易被忽略。

第一个是 Payload encoding 勾选。默认情况下 Burp 会把 payload 里的特殊字符做 URL 编码，比如#会变成%23、/会变成%2f。目录扫描和备份文件测试时，路径里的/是必须原样保留的，否则请求会全部打在一个错误路径上。我一般在 Payload Options 里取消 URL-encode，让 payload 原样插入。

第二个是 Grep-Match。在 Intruder 的 Settings 选项卡里加一条 Grep - Match 规则，比如抓root、password、jdbc:、BEGIN RSA PRIVATE KEY、<property这些关键词。响应包里一旦命中其中任何一个，Intruder 结果区会自动用勾标出来。这样就不用一条条看响应内容里有没有真正的泄露痕迹，只凭关键词命中数量就能快速定位高价值目标。

第三个是重定向处理。遇到登录接口返回 302 时，默认设置不会跟随重定向，导致响应长度差异不明显。建议在 Settings 里的 Redirections 选项选择 All，或者手动把请求发到 Burp 的 Cookie 容器里处理。不过要注意，跟踪重定向会增加耗时，对纯目录扫描不划算，建议只在口令爆破场景开启。

3.3 Resource Pool 与线程控制：低配机器也能跑完 backup 字典

跑字典死在资源池上的情况太常见了。Burp 默认的资源池不限制最大并发，一旦 filename 字典组合出来的请求数超过几万个，线程会疯狂抢占网络连接，目标服务器也可能直接封 IP 或断连。

我通常的做法是给每个扫描任务建独立 Resource Pool。在 Burp 右上角 Resource Pool 面板里新建一个组，Maximum concurrent requests 设置为 5 或 10，Delay between requests 设置在 50 到 200 毫秒之间。为什么要加延时？因为多数 WAF 和反爬策略只盯着高频请求，5 线程加 100 毫秒延迟可以把请求频率降到每秒 10 次以内，反而比暴力超时更稳定。

具体线程参数可以参考这个表：

还有一个经验：先用一个 10 文件行的小样本试跑一遍，确认 Burp 的请求格式和 GREP 规则没写错，再全量加载。这比跑完 5 万个请求后才发现路径格式错误要省力得多。

4. 框架信息泄露与备份/配置文件检测：拿来就能用的探测流程

字典落到具体场景里才有价值。这一章按三条线讲透：Spring Boot Actuator 和若依框架的路径探测、备份文件组合模式、配置文件泄露排查。

4.1 Spring Boot Actuator 与若依框架的路径探测

先说 Actuator。Spring Boot 项目启用 Actuator 后，会暴露一组/actuator开头的端点。测试时先扫 ACTUATOR 基础路径，再用已知端点列表深入。利用 dir 字典中的常见路径，一个典型的 bash 探测循环如下：

while read path; do code=$(curl -k -s -o /dev/null -w "%{http_code}" "https://target.com/${path}") if [ "$code" != "404" ]; then echo "$code ${path}" fi done < dict/dir.txt

这段脚本的逻辑是逐行读取 dir 字典，把每个路径拼到目标域名后面，用curl -s静默请求，-w "%{http_code}"只输出状态码。-k是为了在目标证书不正规时不触发报错。若依框架的路径也是同理，把/prod-api/、/dev-api/、/druid/这些词条提前放到字典头部，能更快遇到高价值响应。

如果扫描到/actuator返回 200，紧接着就要确认端点是否真正开放。用 curl 直接请求/actuator/health和/actuator/env，/actuator/env返回环境变量时通常伴随jdbc:或password字段。这一步必须手工验证，防止扫描器把 200 当成漏洞而忽略实际内容。

4.2 备份文件组合模式：文件名与后缀排列扫描

摘要里反复提“filename 字典使用组合模式”，这是整套资源里最值得重点讲的技巧。所谓组合模式，就是把字典里的文件名和后缀列表做笛卡尔积，生成www.zip、www.bak、admin.sql、config.tar.gz这类完整路径。

写一个 Python 脚本快速生成测试列表：

import itertools names = [line.strip() for line in open("dict/filename.txt", encoding="utf-8") if line.strip()] exts = [".zip", ".tar.gz", ".sql", ".bak", ".rar", ".txt", ".7z", ".gz"] with open("backup_wordlist.txt", "w", encoding="utf-8") as fp: for name, ext in itertools.product(names, exts): fp.write(f"{name}{ext}\n")

这段代码做了三件事：第一，用itertools.product生成文件名和后缀的全组合；第二，把组合结果写入新文件backup_wordlist.txt；第三，生成的是一个可直接刷进 Burp 的普通文本。你可以根据目标系统的备份习惯增删后缀，比如 Windows 服务器常见.rar和.7z，Linux 服务器常见.tar.gz和.sql。

拿到backup_wordlist.txt后，直接加载到 Burp Intruder 的 Sniper 模式，插入位置放在域名后面。实际测试时经常出现“当开发人员在线上环境中对源代码进行了备份操作，并且将备份文件放在了 web 目录下”的场景，这种备份文件一旦被访问到，往往就是源码泄露的开始。用组合模式测试的价值在于，它并不假设备份文件名一定是www.zip，而是覆盖了所有常见命名和后缀的可能。

4.3 配置文件泄露：logback.xml、Maven settings.xml 的排查

配置文件泄露与目录扫描是两回事。很多人扫完目录只看几个状态码，却不关注响应内容里的关键词。正确的做法是把返回 200 的路径全部抓下来，再用关键词过滤。

推荐使用 Burp Intruder 的 Grep-Match 功能，关键词至少包含这些：password、username、jdbc:、token、secret、api_key、access_key、<property、logging.file.path。一旦响应里出现这些词，这个 200 的路径就值得手工打开看内容。

具体到配置文件本身，有几个固定套路值得记：

其中 Maven 配置文件的排查经常被忽略。很多 Spring Boot 项目通过 Maven 构建，settings.xml一旦泄露，私服里的所有依赖都可能被拖走，而且这个文件往往就在 web 目录的备份包里。若依框架则通常把数据库配置文件放在resource目录下，打包到 jar 后路径会变成/BOOT-INF/classes/application-druid.yml，扫描时不要漏掉这条。

5. 避坑指南：渗透字典压测中容易翻车的五个问题

字典本身不会坑人，使用方式会。这一章把我实际踩过的坑按“现象 → 原因 → 解决”写清楚，每一条都能省你半天时间。

5.1 现象：目录扫描返回一大片 200，但人工访问全是统一登录页

造成这种情况最常见的原因是目标框架把不存在的路由也返回 200，比如 Vue 前端路由或 Spring Boot 的default page。若依框架尤其典型，它会在网关层统一处理，不存在的路径也返回一个统一的 HTML 页面。

• 原因：响应码不是有效判断条件，框架的全局异常处理把 404 吞掉，返回 200。
• 解决：对比响应长度和响应内容。若所有 200 的页面Content-Length一致，说明这些响应是同一种兜底页面，真正的目录在扫描结果里的特征应是响应长度波动。用 Burp 的Inspect面板按大小排序，或者给 Grep-Match 加一个 target 页面独有的关键词，然后反选过滤。

5.2 现象：备份文件组合模式跑到一半 Intruder 卡死，进度条再也不动

这是资源池设置不当的直接后果。组合模式生成的请求数量轻松上万，如果同时在 Intruder 里跑多个 Tab，Burp 的线程会被拖垮。

• 原因：Resource Pool 没有限制最大并发，系统文件句柄或网络连接耗尽。
• 解决：单独建一个 Resource Pool，最大并发调成 3，延迟 200ms。另外一个更稳妥的做法是先用上面第 4 节的脚本生成完整backup_wordlist.txt，然后用 Sniper 模式一次性跑，而不是在 Intruder 里实时做笛卡尔积。

5.3 现象：从 CSV 字典加载 payload 时，Burp 把一个条目拆分成了多个

passwords.csv、ics-default-passwords.csv这类文件用逗号分隔字段，但 Burp 的 Simple list 默认按行读取，不会主动识别 CSV 结构。如果直接加载，一行里的多个字段会被当成一整个 payload，导致口令爆破失败。

• 原因：Burp 不会处理 CSV 中的分隔符，整行被当作单一字符串。
• 解决：把 CSV 转换成每行一个 payload 的纯文本格式，比如用awk -F',' '{print $1}'提取第一列，或手动用 Excel 另存为 CSV 后导入前先做一列去重。对 Scada_Password.csv 这类工控口令表，建议只取用户名和密码两列，分别输出到单独文件再加载。

5.4 现象：中文用户名或带#的 payload 请求后乱码，目标系统返回参数错误

这套字典里的 username 文件大概率包含中文姓名，但终端或 Burp 的环境编码不对，导致发送出去的请求是 GBK 字节流，目标系统按 UTF-8 解码就出现乱码。

• 原因：字典文件本身编码可能是 GBK 或 UTF-16，Burp 默认按 UTF-8 读取。
• 解决：先用file命令检查字典编码，再用iconv -f GBK -t UTF-8 dict/username.txt -o username_utf8.txt做转码。如果服务器本身是 GBK 编码（常见于老牌 OA 系统），则反过来转成 GBK 后加载。编码问题不解决，再强的字典也发挥不出作用。

5.5 现象：lic-dtct，等等，别用奇怪的工具，直接说：弱口令字典扫出的结果大量误报

默认口令字典里有不少口令是admin/admin、test/test这类测试账号。扫描器一旦发现登录接口返回了跳转或welcome字样，就容易判定为弱口令。但实际很多系统前端会用 JavaScript 校验，口令错误也返回 200，只是页面内容里带着错误提示。

• 原因：只对比响应码，没有对比响应主题。
• 解决：把登录请求的响应内容拉出来，用 Grep-Match 同时匹配“success”“welcome”“index.jsp”“修改密码”等关键词，多个关键词任一命中才判定成功。如果是 JSON 接口，直接匹配"code":0之类的业务字段。这一步能把误报率压缩到 5% 以下。

6. 让字典保持新鲜：合并增量、去重排序并沉淀成自己的语料库

字典用得再熟，半年不更新也会失效。框架一改版路径就变，新中间件也会带来新端点，所以最后一章分享一个我每天都会跑一遍的维护流。

先做一个最基础的清理，把所有类别字典合并，去重并按长度排序：

cat dict/dir.txt dict/filename.txt dict/dns.txt | \ sed 's/\r$//' | \ grep -v '^$' | \ sort -u > combined_wordlist.txt

sed 's/\r$//'用来干掉 Windows 换行符，grep -v '^$'移除空行，sort -u去重排序。这一步执行完就能得到一份干净可复用的大字典。注意不要把所有分类强行混在一起，组合模式下还是保持filename、dir各自独立。

接着是从实战回流增量。我在跑完一次 Burp 扫描后，会把返回非 404 但没在字典里出现的路径单独存成一个new_paths.txt，定期合并进 dir 字典。文件备份名也一样，如果目标系统用了20240101_backup.zip这种带日期的命名，就把20240101这个样式提取出来，追加到 filename 字典，下一次遇到同类命名习惯的系统就能直接命中。

如果你在维护过程中发现某一类固定框架路径频繁变化，比如 Spring Boot Actuator 端点在不同版本里增删，建议单独建一个framework_paths.txt。我自己习惯把/actuator/health、/actuator/beans、/actuator/configprops、若依的/prod-api/、/dev-api/、/tool/gen全放进来，每次扫描前先用这个文件打头阵，再跑通用 dir 字典。这套逻辑比祈祷字典刚好覆盖目标框架要可靠得多。

字典整合不是越大越好。盲目合并会产生大量重复路径，让 Intruder 空转。所以我每周做一次全量清理：先sort -u去重，再用wc -l对比合并前后行数，确认增量是真实的新路径而不是重复数据。如果发现某个文件突然膨胀了 30% 以上，十有八九是重复爬取合并出了问题，需要回查来源文件。

从那以后我每次拿到新目标，都会强制走一遍这个流程：先加载framework_paths.txt快速确认框架指纹，再挂 filename 组合模式扫备份，最后才跑整体 dir 字典。这个过程花不了五分钟，但能避免在错误路径上砸下去几千个请求。字典是死的，使用顺序和维护习惯才是让它在信息泄露测试里持续生效的关键，希望这份使用笔记帮你在下一次授权测试里少走几步弯路。

本文还有配套的精品资源，点击获取