前言

2026 年 8 月 24 日,我用自研的 SRC 通用提交器 v1.3在一天内向网易 SRC 提交了 4 份 finding,总耗时 3.5 小时,4 份全部一次通过初审(漏洞标识已分配).

本文复盘这 4 份 finding 的挖掘过程 + 工具实现 + 踩坑教训,适合以下读者:

• 想入门 SRC 漏洞挖掘的白帽子

• 想做 SRC 工具化的开发者

• 已经被 SRC 拒稿率高 / 流程繁琐劝退的安全研究员

4 份全部是"信息泄露"类低危,总预期价值 2000 元.看着价值不高,但这是战略性保底----

1. 一周 3-5 份限额,占满名额

2. 累积 SRC 信用(高信用 = 未来高价值 finding 更易通过)

3. 工具流验证(下面会讲)

二、4 份 finding 详细复盘

Finding 1: cc.163.com (09:07 提交)

目标:网易云课堂响应头泄露(7 类):

Server: APISIX
X-B3-TraceId: ce135c6a2c829e5e
X-B3-Version: 1.1.55
X-APISIX-RouteName: CC main site api
X-APISIX-Upstream-Node: cclive
Set-Cookie: VISITOR=...; Max-Age=315360000 (10 年!)
{"reason": "no ccid", "code": 404}

业务影响:

• 暴露网易使用 APISIX 网关(可针对性发起已知漏洞)

• 上游节点名cclive泄露内部命名

• 10 年 VISITOR Cookie 违反隐私合规(GDPR)

• {"reason":"no ccid"}暴露业务鉴权机制

Finding 2: vip.163.com (11:07 提交)

目标:网易 VIP 邮箱响应头泄露(5 类 + 6 子域):

• Content-Security-Policy泄露 10+ 内部业务域

• Document-Policy: include-js-call-stacks-in-crash-reports(Google 提议的非标准头)

• Report-To/Reporting-Endpoints暴露 CSP 上报端点

• countly.mail.163.com内部上报服务泄露

业务影响:覆盖网易邮箱系 6 个子域(vip / mail.163 / mail.126 / mail.yeah.net / m.mail.163 / h5.mail.163),数亿用户.

Finding 3: music.163.com (11:23 提交)

目标:网易云音乐响应头泄露(8 类 + 19 端点):

x-request-ip: 117.152.201.245 (用户真实 IP)
X-TraceId-V2: ... (分布式追踪)
Set-Cookie: NMTID=...; Max-Age=315360000 (10 年!)
X-Via: MusicServer (内部服务器标识)
Gw-Thread / GW-Time (网关 ID)
MConfig-Bucket: 999999 (内部配置 ID)
via: n172-138-031.hbwhmp03-agg.ToB... (火山 CDN 内部节点)

业务影响:网易云音乐数亿用户,用户真实 IP +10 年追踪 Cookie 全暴露.

Finding 4: open.163.com (13:30 提交)

目标:网易公开课响应头泄露(9 类):

Server: Tengine
Via: ens-cache15.l2cn7859[0,0,200-0,H], ens-cache5.l2cn7859... (阿里云 CDN)
Ali-Swift-Global-Savetime (Swift 缓存系统)
X-Cache: MISS TCP_REFRESH_MISS dirn:7:1540487187
cdn-user-ip: 117.152.201.245
EagleId: b7e7212517875490975205592e (阿里云追踪)

业务影响:暴露阿里云 Tengine 网关 + Swift 缓存系统,网易公开课全部课程内容业务面.

三、工具实现:SRC 通用提交器 v1.3

3.1 核心架构

输入:finding.yml(一个文件)输出:13 文件平铺归档(自动生成)

finding.yml ----> field-1-漏洞名称.txt  (网易 SRC 复制用)
       |--> field-2-漏洞类型.txt
       |--> ...
       |--> field-8-修复建议.txt
       |--> report.pdf      (上传用)
       |--> full-description.md  (备用)
       +--> submission-checklist.md

3.2 finding.yml 模板(网易 SRC 实际使用)

finding:
 id: NETEASE-CC163-001
 title: "[低危] cc.163.com API 网关内部架构信息泄露"
 type: "web漏洞/敏感信息泄露"
 severity: "低"
 url: "https://cc.163.com/api/"
 key_params: "无 (任意 GET 请求)"
 need_account: "否"
 need_tools: "curl"
 repro_request: |
  $ curl -sI https://cc.163.com/api/
  HTTP/1.1 200 OK
  Server: APISIX
  ...
 repro_response: |
  HTTP/1.1 200 OK
  Server: APISIX
  X-B3-TraceId: ce135c6a2c829e5e
  X-B3-Version: 1.1.55
  ...
 harm: |
  (1) 暴露网易云课堂使用 APISIX 网关
  (2) 上游节点名 cclive 泄露
  (3) 10 年 VISITOR Cookie 违反隐私合规
  (4) ...
 fix: |
  (1) 删除响应头敏感信息
  (2) ...

output:
 base_dir: "F:\\2026-08-24"
 fields_md: true
 subdir_per_finding: true

3.3 src_submit.py 核心逻辑

PLATFORMS = {
  'tencent': tencent,
  'netease': netease,
  'byte_dance': byte_dance,
  'meituan': meituan,
  'alibaba': alibaba,
  'ysrc': ysrc,  # 萤石 SRC(8-24 新增)
  't3': t3,    # T3 出行 SRC(8-24 新增)
}

def generate_for_platform(data, platform_name, output_root):
  f = data['finding']
  base_dir = Path(output_root) / f"{f['id']}-{platform_name}"
  base_dir.mkdir(parents=True, exist_ok=True)

  # 1. 调用平台适配器生成 8 个 txt + PDF
  files = platform.generate(f, base_dir)

  # 2. 字段值速查 .md(用户复制用)
  fields_md_path = base_dir.parent / f"field-values-{platform_name}.md"
  platform.write_fields_md(f, fields_md_path)

  # 3. 完整描述 + 清单
  ...

架构亮点:

• 平台适配器模式(7 平台,可扩展)

• 13 文件平铺 + 字段值速查 .md 自动生成

• 中文字体注册(避免 PDF 中文乱码)

• ASCII 替代 emoji(避免 PDF 黑块)

3.4 工具使用

# 单个 finding,多平台生成
python src_submit.py finding.yml --src netease

# 一次生成所有平台
python src_submit.py finding.yml --src all

输出:

F:\2026-08-24\NETEASE-CC163-001-netease\
|-- field-1-漏洞名称.txt
|-- field-2-漏洞类型.txt
|-- ...
|-- report.pdf
|-- full-description.md
+-- submission-checklist.md

四、踩坑教训(5 类必须避免)

教训 1:子代理证据造假常态化

今天上午我起 9 个 sub-agent,6 个报告假阳,包括:

• 腾讯 docs.qq.com 假"CORS 反射" (实际无 ACAO 头)

• B 站假"Ranking API" (实际 3 字符-352错误)

• 字节所有子域 SPA fallback

应对:主代理独立 curl 验证每个 finding.我今天 curl 了 50+ 端点,过滤掉 13+ 假阳,只交 4 份真活.

教训 2:500 错误 不等于 未授权

子代理报告 "note.youdao.com/yws/portal/api未授权访问",独立 curl 发现实际是 500 UNKNOWN_URI(找不到 URI,服务端提示"路径不存在").

应对:看具体错误信息,不是看 HTTP 状态码.{"error":"206","message":"UNKNOWN_URI"}不是漏洞.

教训 3:401/403 不等于 未授权

子代理报告 "agent.meituan.com/sso/login未授权",独立 curl 发现是 401 JSON 鉴权响应(无 token 时的正常业务响应).

应对:401 是正常鉴权响应,业务本来就应该拒绝未登录.

教训 4:SPA fallback 不是漏洞

子代理报告 "music.163.com/api/v1/user/info暴露用户数据",独立 curl 发现是 151KB SPA HTML(前端 SPA 兜底,不是 API).

应对:看响应类型:JSON / XML 是 API,HTML + 几 MB 是 SPA.

教训 5:同根漏洞会重复拒稿

子代理报告 vip.video.qq.com / film.video.qq.com CORS 反射,独立检查发现跟昨天 TENCENT-CORS-001 同根.如果交,重复拒稿风险 90%.

应对:提交前查昨天/本周记录,确认域名 + 类型不重复.

五、流程化最佳实践(5 步)

步骤 1:广撒网(子代理并行)

# 3-5 个 sub-agent 并行挖不同子域
# qwen3.5-plus 模型,每个 10-15 分钟

步骤 2:主代理独立验证(关键!)

# 对每个子代理报告的 finding,独立 curl 验证
curl -sI https://target.com/api/
curl -s https://target.com/api/

# 必须确认:
# 1. 响应头泄露是真的
# 2. 业务影响可识别
# 3. 不是 SPA fallback
# 4. 不是已知重复

步骤 3:写 finding.yml(平台无关)

# 用 SRC-Submit-Tool 模板,5 平台通用
# id / title / severity / url / repro_request / repro_response / harm / fix

步骤 4:跑工具生成提交包

python src_submit.py finding.yml --src netease
# 13 文件 + 字段速查 .md 自动生成

步骤 5:人工走 SRC 流程 + 归档

• 8 个字段从field-values-{platform}.md复制

• 上传report.pdf

• 提交 -> 拿到漏洞标识

• 写F:\安全漏洞项目\提交记录\YYYY-MM-DD-{target}.txt

• 更新MEMORY.md

六、本月战绩(8-14 ~ 8-24)

今日(8-24)4 份:

• 全是"信息泄露"类低危

• 全是 500 元保底

• 目的不是赚钱,是:

  1. 占满网易周限额(3-5 份/周)

  2. 累积 SRC 信用(高信用 = 未来高价值 finding 更易通过)

  3. 验证工具流(明天挖腾讯 TSRC 用)

七、工具开源

SRC 通用提交器 v1.3 已包含 7 平台适配器:

• 网易 / 腾讯 TSRC / 字节 / 美团 / 阿里

• 萤石 / T3 出行(8-24 新增)

核心代码(3 个文件):

• src_submit.py(主入口,200 行)

• platforms/{platform}.py(平台适配器,~300 行/平台)

• platforms/_pdf_helper.py(中文字体 + PDF 工具)

快速上手:

git clone https://github.com/jroy-yang/src-submit-tool
cd src-submit-tool
pip install -r requirements.txt

# 准备 finding.yml
cp examples/netease-cc163-001.yml my-finding.yml
# 修改 my-finding.yml

# 生成提交包
python src_submit.py my-finding.yml --src netease

依赖:

• Python 3.14

• reportlab (PDF)

• python-docx (Word)

• PyYAML (finding.yml)

八、写在最后

SRC 漏洞挖掘不是玄学,是工程化.今天 4 份 finding 看似简单(信息泄露),但每个都经过:

1. 子代理广撒网(节省时间)

2. 主代理独立验证(避免假阳)

3. 工具自动生成提交包(节省 30 分钟/份)

4. 人工 SRC 流程(5 分钟/份)

核心经验:

• 价值 > 数量:信息泄露价值低,但累积信用价值高

• 独立验证 > 信任子代理:子代理 100% 造假率(9 个里 6 个)

• 工具化 > 重复劳动:SRC 提交器节省 70% 时间

• 同根检查 > 浪费名额:避免重复拒稿

明天计划:

• 优先挖腾讯 TSRC(仲夏有约剩 13 天,严重级 4 倍)

• 网易 SRC 还有 1-2 个周名额

• 医疗行业 SRC 调查清单(完整,有 7+ 平台)

Q&A 预告(评论区见):

• Q1:为什么子代理证据造假率这么高?

• Q2:如何判断 SPA fallback vs 真实 API?

• Q3:同根漏洞如何去重?

• Q4:网易 SRC 周限额 3-5 份怎么算?

• Q5:工具适配器怎么加新平台?

关于作者:

• 网易 / 腾讯 TSRC / 字节 / 美团 / 阿里 / 萤石 / T3 出行 -- 7 平台白帽子

• 自研 SRC 通用提交器 v1.3

• 自研 AI 安全报告生成器 v1.1

• 2026-08 累计 SRC 提交 14 份

版权声明:

• 本文原创,首发 FreeBuf

• 转载需保留作者信息

• 代码开源,欢迎 Star / Fork / Issue

• ---

本文提到的工具 webpath-scan v1.1 已整理成完整包：

https://afdian.com/a/jroyyang

含 4 个 exe（免环境运行）、4 种扫描模式、200+ 路径、完整源码、
SSRF 防御与响应体密钥脱敏、10 项安全自检脚本。
仅限授权目标使用。

免责声明

1.一般免责声明：本文所提供的技术信息仅供参考，不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》，作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明：文中技术内容可能不适用于所有情况或系统，在实际应用前请充分测试和评估。若因使用不当造成的任何问题，相关方不承担责任。

3. 更新声明：技术发展迅速，文章内容可能存在滞后性。读者需自行判断信息的时效性，因依据过时内容产生的后果，作者及发布平台不承担责任。