注册白帽子快一年了，一直没正经交过漏洞。不是不想，是总觉得「自己还不够格」——直到上个月，我对自己说：别等了，动手吧。
三周时间，我跑了三个项目：一家金融科技公司、一家物联网硬件厂商、一个视频平台。三家公司，三种完全不同的安全成熟度，三种截然不同的测试体验。这篇文章是这二十一天的完整复盘——踩过的坑、用过的方法、以及最重要的，那些 SRC 不会在公开文档里告诉你的潜规则。
开篇：从注册到实战
一切开始得很简单：在 漏洞盒子 注册白帽子身份，签署 SRC 保密协议，然后从已授权的测试目标列表里挑了三家看上去「能啃得动」的。
选目标有讲究——我挑了三个行业跨度大的，不是为了找洞更多，而是为了在最短时间内接触最多的技术栈。金融科技大概率有严格的合规要求，IoT 厂商的安全投入通常偏弱，视频平台则介于两者之间。事实证明，这个判断基本准确。
拿到授权后，第一件事不是扫端口，而是建一个项目文件夹、一个笔记文档、一个方法论 checklist。每测一个点就勾掉一项，发现新思路就追加到 checklist 里。这个习惯在后来的项目中救了我很多次。
SRC 测试不是黑客电影里的「一个命令黑进去」，而是一场信息搜集的持久战。谁的信息更全，谁的胜算更大。
资产发现方法论
我的资产发现流程分为四步，按顺序执行，每一步产出的结果作为下一步的输入：
| 步骤 | 工具 | 产出 |
|---|---|---|
| 1. 子域名枚举（被动） | Subfinder, 证书透明度日志 | 原始域名列表 |
| 2. DNS 解析与筛选 | MassDNS + 自定义解析脚本 | 可解析域名列表 |
| 3. HTTP 存活探测 | httpx | 存活 Web 资产列表 |
| 4. 截图与指纹识别 | gowitness + 自定义指纹库 | 可视化资产地图 |
手动跑一遍这些步骤很费时，于是我写了一个 pentest-recon.cjs 脚本把它们串起来：
// pentest-recon.cjs — 自动化资产发现流水线
// 用法: node pentest-recon.cjs target.com
const { execSync } = require('child_process');
const fs = require('fs');
const target = process.argv[2];
const dir = `./recon/${target}`;
fs.mkdirSync(dir, { recursive: true });
// 1. 被动子域名枚举
console.log('[1/4] 被动子域名搜集...');
execSync(`subfinder -d ${target} -o ${dir}/subdomains.txt`);
// 2. DNS 解析
console.log('[2/4] DNS 解析...');
execSync(`massdns -r lists/resolvers.txt -t A ${dir}/subdomains.txt -o S > ${dir}/resolved.txt`);
// 3. HTTP 存活探测
console.log('[3/4] 存活探测...');
execSync(`cat ${dir}/resolved.txt | awk '{print $1}' | httpx -silent -o ${dir}/alive.txt`);
// 4. 截图
console.log('[4/4] 截图...');
execSync(`gowitness file -f ${dir}/alive.txt -P ${dir}/screenshots`);
console.log('✅ 完成，结果在 ' + dir);自动化之后，我的工作模式变成了：跑脚本的时候去喝杯咖啡，回来对着截图和资产列表开始真正的分析。重复劳动交给机器，脑力留给需要判断力的地方——这是我这三周最大的效率提升。
自动化不是为了取代你，而是为了让你在真正需要判断力的时候精力充沛。
技术栈指纹识别
拿到存活资产后，下一步是搞清楚对面跑的是什么。你连对面用的什么技术都不知道，怎么找漏洞？
我的指纹识别三板斧：
- Server 响应头：Tengine、OpenResty、Apache、Nginx，一眼就能看出个大概。Tengine 通常意味着阿里云系的部署，OpenResty 则暗示可能是 Lua 自定义网关。
- 前端 JS 包：umi.js（4MB 主 chunk 是标志性特征）、Nuxt.js（页面源码里有
__NUXT__JSON）、Vue SPA（#app+ vendor 包）。 - 配置中心：Apollo 配置中心可以通过
releaseKey的格式特征识别出来。 - WAF 指纹：Alibaba Cloud WAF 会在 Cookie 里留下
acw_tc；自定义 WAF 则可能返回 412 Precondition Failed。
三家项目的技术栈对比如下：
| 维度 | 金融科技 | IoT 厂商 | 视频平台 |
|---|---|---|---|
| Web 服务器 | Tengine | Nginx | OpenResty |
| 前端框架 | umi.js (4MB) | Vue SPA | Nuxt.js |
| 后端语言 | Java (Spring) | PHP | Go |
| 配置中心 | Apollo | 无 | 自研 |
| WAF | Alibaba Cloud WAF | 无 | 自定义 WAF (412) |
| Cloud Provider | 阿里云 | 腾讯云 | 混合云 |
| 登录方式 | 短信 + 密码 | 手机号 + 验证码 | OAuth + WBI 签名 |
看到这个表的时候，我心里对三个项目的安全水位已经有了个大概的判断。金融科技有合规压力，但业务复杂容易留漏洞；IoT 厂商技术栈简单，但安全投入最少；视频平台技术栈最复杂，WAF 是自研的——说明他们真有安全团队在维护。
前端 JS 反编译的意外收获
这是我这三周学到的最重要的方法，没有之一。
现代前端应用打包出来的 JS 文件，尤其是 SPA，几乎包含了整个前端应用的「地图」：路由路径、API 端点、内部域名、甚至有时候硬编码的密钥和注释。
我的做法很简单：
- 从浏览器开发者工具里找到主 JS bundle（通常是
umi.js、app.js、main.*.js这种） - 下载下来，用
grep搜索关键模式：/api/、route、internal、test、dev、pre、.com、.cn - 把匹配到的结果整理成资产清单
金融科技项目的前端 JS 里，我翻到了一个支付系统的路由模式——代码里定义了一系列 routeXXX 格式的支付路由路径，虽然不是直接漏洞，但让我对业务逻辑有了全局视图。
IoT 厂商的项目才是真正的金矿。一个 4MB 的 umi.js 文件里，我找到了 8 个内部环境域名：
# 从 umi.js 提取的内部域名
api-dev.xxx.com # 开发环境 API
api-test.xxx.com # 测试环境 API
api-pre.xxx.com # 预发布环境 API
api-internal.xxx.com # 内部 API
admin.xxx.com # 管理后台
admin-dev.xxx.com # 开发管理后台
mqtt-dev.xxx.com # MQTT 开发服务器
oss-internal.xxx.com # 内部对象存储最让我惊讶的是，预发布环境 api-pre.xxx.com 公网可访问，而且和生产环境运行着同样的代码和数据库——只是数据量少一些。这相当于一个完整的「影子系统」暴露在公网上，没有任何额外的访问控制。
但是，这里有个重要的教训：JS 包里的信息越多，说明这家公司的安全成熟度越低。反过来，视频平台的 JS 包经过混淆，路由全是 hash 模式，API 端点做了动态拼接——他们显然知道前端 JS 是信息泄露的重灾区，做了针对性的防护。
JS bundle 是信息泄露的富矿，但它的存在本身就是一面镜子——照出这家公司对安全的认知水平。
API 鉴权与 CORS
资产摸清了，技术栈知道了，接下来是真正的测试环节。
支付 API 鉴权绕过
金融科技项目里，我发现一个支付状态的查询接口，不加任何身份凭证，直接 POST 请求就能返回业务数据。返回的 result: 0 表示业务成功——不是 401、不是 403，是业务层面的成功。这意味着支付流水号如果可预测或可遍历，就能批量获取交易信息。
这个漏洞，是我唯一一个拿到确认排期的。
CORS 配置缺陷
在金融科技和 IoT 项目上，我都发现了 CORS 配置问题：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true通配符 + 允许凭据，这是教科书级别的 CORS 配置错误。但问题是——我能拿它做什么？
理想情况下，配合一个已登录用户访问恶意页面，攻击者可以跨域读取敏感数据。但在 SRC 的语境下，你只证明了「CORS 配置有问题」，却没有证明「谁能通过这个漏洞受到什么实际损失」。SRC 审核团队给我的回复很明确：没有完整的攻击链，CORS 配置缺陷单独不予受理。
即使 Access-Control-Allow-Origin: * 和 credentials: true 同时存在，SRC 要求你证明这能造成实际危害。需要找到具体的用户敏感数据接口，配合 CSRF 或 XSS 构成完整攻击链。
✅ 教训：CORS 漏洞要和其他漏洞组合提交，单独提交会被拒。
在 IoT 项目的 DNS 记录里发现内部 IP 地址段，单独提交后同样被拒。SRC 认为内部 IP 泄露本身不构成可衡量的安全风险，除非能证明攻击者可以利用这些 IP 做进一步渗透。
✅ 教训：信息泄露类漏洞需要附带攻击路径，证明这些信息如何被利用。
预发布环境可被公网访问，理论上可以获取未发布的业务数据和测试账号。但 SRC 认为预发布环境的数据是脱敏或非真实的，不构成用户数据泄露风险。
✅ 教训：预发布环境暴露通常被归为「低危」甚至「无风险」，除非你能证明生产数据也在上面。
这三个坑让我明白了一个残酷的事实：SRC 不是一个「找到漏洞就行」的地方，而是一个「证明漏洞有价值」的地方。同样是漏洞，能直接造成用户数据泄露或资金损失的，和「理论上可能被利用」的，在 SRC 的眼里是两种完全不同的东西。
SRC 审核团队不关心技术上的「可能性」，只关心业务上的「必然性」。翻译成人话：得证明这玩意儿真的能让人丢钱或丢数据。
安全成熟度横向对比
三家公司的安全水位差异巨大，我把它们放在一起对比，结论非常直观：
| 维度 | 金融科技 | IoT 厂商 | 视频平台 |
|---|---|---|---|
| 安全成熟度 | 中等 | 低 | 高 |
| WAF | 云 WAF（基础规则） | 无 | 自研 WAF（412 拦截） |
| API 鉴权 | 部分接口无鉴权 | 基本鉴权均有 | WBI 签名 + 严格鉴权 |
| CORS | 通配符 + 凭据 | 通配符 + 凭据 | 严格白名单 |
| 前端安全 | 未混淆，含内部路由 | 未混淆，含全部内部域名 | 混淆 + hash 路由 + 动态拼接 |
| Cookie 安全 | 部分 HTTPOnly | 无 HTTPOnly | 全 HTTPOnly + SameSite |
| 速率限制 | 较弱 | 无 | 严格（单 IP 限频） |
| 测试结果 | 发现 1 个中危（已确认） | 发现多个信息泄露，部分被拒 | 无发现 |
这个表格说明了两个问题：
- 你的时间应该花在哪里：IoT 厂商虽然安全投入少，但信息泄露类漏洞 SRC 又不收；金融科技找到了一个支付鉴权问题，是唯一确认排期的漏洞；视频平台什么都不给——但「什么都没找到」本身就是一个发现。
- 安全是成本，不是功能：视频平台有自研 WAF、有严格鉴权、有前端混淆，每一层都在说「我们在这上面花了钱」。IoT 厂商什么都没有，但 SRC 审核标准并不会因为对方安全弱就降低门槛。
提交策略与踩坑
三周时间，我提交了 5 个漏洞，确认排期 1 个，被拒 4 个。成功率 20%，惨不忍睹。但每一个被拒的漏洞都让我学到了一些东西。
什么会被拒
| 漏洞类型 | 提交次数 | 确认次数 | 被拒原因 |
|---|---|---|---|
| DNS 内部 IP 泄露 | 1 | 0 | 无实际攻击链 |
| CORS 通配符 | 2 | 0 | 未证明能获取敏感数据 |
| 预发布环境暴露 | 1 | 0 | 预发布数据非生产数据 |
| 支付 API 无鉴权 | 1 | 1 | — |
什么才有效
从这些被拒的教训里，我总结出了 SRC 提交的「黄金法则」：
- 可证明的 impact：能直接获取用户数据、能执行未授权操作、能导致资金损失——这些是 SRC 最关心的。
- 完整的攻击链：不只是「这里有个洞」，而是「A + B + C = 攻击者能成功窃取 X」。每一步都要可复现。
- 清晰的复现步骤：包含
curl命令 + 请求/响应截图 + 预期的安全影响。审核人员每天看几十个报告，你的报告越容易复现，越容易被确认。 - 合理的 CVSS 评分：不要虚报高分，也不要低估。SRC 有自己的评分逻辑，虚报高分只会降低你的可信度。
提交顺序的学问
我学到的另一个教训是提交顺序：
- 先提交信息泄露类：这类漏洞审核最快，虽然被拒率高，但反馈快，能帮你快速理解 SRC 的审核标准。
- 再提逻辑漏洞：这类漏洞通常需要各种鉴权 token 和测试账号，准备工作量大，但确认率高。
- 最后提交越权类：越权漏洞需要完整的前后端理解，评审周期最长，放在最后慢慢磨。
📌 漏洞名称和影响范围
📌 复现步骤（含具体 URL 和请求参数）
📌 完整的 curl 命令（可以直接复制粘贴复现）
📌 请求/响应截图（标注关键信息）
📌 业务影响说明（为什么这是个问题）
📌 CVSS 评分（附评分向量）
✅ 格式清晰、信息完整、可复现——这是 SRC 审核最看重的三点。
结语
三周时间，三个项目，五个提交，一个确认。表面上看，这个成绩单并不亮眼。但对我来说，这二十一天的收获远不止一个漏洞确认——它让我建立了一套完整的白帽测试方法论，从资产发现到漏洞提交，每一个环节都有了自己的标准和流程。
几个核心 takeaways：
- 自动化是力量倍增器。
pentest-recon.cjs把重复劳动压缩到了极致，让我把精力放在真正需要判断力的地方。任何白帽子都应该建立一个自己的工具链。 - 前端 JS 是最容易被忽视的信息泄露面。 现代 SPA 应用把整个应用地图打包进一个 JS 文件里，不翻一遍就去做渗透，等于闭着眼睛打仗。
- 安全成熟度因行业天差地别。 金融科技有合规托底，IoT 厂商几乎裸奔，大厂自研 WAF 让新手无从下手——选对目标比测试技术更重要。
- 「没找到漏洞」也是一个发现。 视频平台什么都没给，但反过来证明了他们的安全投入是有效的。这种「被防御住」的体验本身，就是一次高水平的实战训练。
- SRC 不是 CTF。 它不关心你秀了多少技巧，只关心你提交的漏洞有没有实际业务影响。调整心态，从「找洞」切换到「证明风险」。
方法论还在迭代，手头的 pentest-recon.cjs 也在不断更新。下一步计划把这套流程整理成更完整的工具链，也计划继续挑战更多 SRC 项目——不为排名，就为了在实战中保持手感。
安全这条路很长，三周才刚开了个头。