漏洞分析 | 如何通过YouTube API隐藏参数获取创作者邮箱并获$20,000奖励

文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

图1：安全测试环境，左侧为终端，右侧为浏览器开发者工具。

想象一下，你精心运营的YouTube频道背后，可能隐藏着泄露你隐私信息的API漏洞。最近，一位安全研究员通过层层剖析，揭示了YouTube API中一处不为人知的“秘密”，这个漏洞最终能导致创作者邮箱被泄露。这不仅是一个技术故事，更是一堂生动的网络安全课。

初探：从API调试信息泄露开始

故事的起点颇具偶然性。一位研究员在测试Google API请求时发现，当向API端点发送一个带有错误参数类型的请求时，服务器除了返回错误，还会“好心”地提供关于该参数的调试信息。

例如，向YouTube的 /youtubei/v1/browse 接口发送POST请求时，故意将本应为字符串的 browseId 参数设置为整数 1。

请求示例：

POST /youtubei/v1/browse HTTP/2
Host: youtubei.googleapis.com
Content-Type: application/json
Content-Length: 164

{
"context": {
"client": {
"clientName": "WEB",
"clientVersion": "2.20241101.01.00",
    }
  },
"browseId": 1
}

服务器响应：

HTTP/2 400 Bad Request
Content-Type: application/json; charset=UTF-8
Server: scaffolding on HTTPServer2

{
"error": {
"code": 400,
"message": "Invalid value at 'browse_id' (TYPE_STRING), 1",
"errors": [
      {
"message": "Invalid value at 'browse_id' (TYPE_STRING), 1",
"reason": "invalid"
      }
    ],
"status": "INVALID_ARGUMENT",
    ...
  }
}

服务器明确指出了 browse_id 的值无效，并告知其正确类型应为字符串（TYPE_STRING）。这就像你问错了问题，对方不仅纠正你，还告诉了正确的提问格式。

YouTube API主要使用JSON格式通信，但它还支持一种不那么常见的格式—— application/json+protobuf （ProtoJson）。这种格式允许以数组形式传递参数值，而无需明确参数名。研究员灵机一动：如果发送一个包含一系列随机数字的ProtoJson请求，如 [1,2,3...30]，API会不会把所有可能的参数名和预期类型都列出来呢？

果然，发送这样一个“乱序”请求后，API返回的错误信息中包含了近三十个参数的详细清单，列举了如 context、browse_id、params、continuation 等参数及其正确数据类型。这简直就是一份活生生的API参数字典！

为了自动化这一“参数字典生成”过程，研究员专门开发了名为 req2proto 的工具。

$ ./req2proto -X POST -u https://youtubei.googleapis.com/youtubei/v1/browse -p youtube.api.pfiinnertube.GetBrowseRequest -o output -d 3

查看 output/youtube/api/pfiinnertube/message.proto 的输出，可以获得该端点的完整请求结构定义（Protobuf格式）。基于此发现，研究员开始寻找其他可能存在隐藏参数并泄露调试信息的API端点。

深入：聚焦创作者频道信息接口

如果你检查过YouTube Studio加载“收益”（Earn）选项卡的请求，可能会注意到这样一条请求：

图2：YouTube Studio界面中的“版权”与“收益”选项卡。

POST /youtubei/v1/creator/get_creator_channels?alt=json HTTP/2
Host: studio.youtube.com
Content-Type: application/json
Cookie: <redacted>

{
"context": {
    ...
  },
"channelIds": [
"UCeGCG8SYUIgFO13NyOe6reQ"
  ],
"mask": {
"channelId": true,
"monetizationStatus": true,
"monetizationDetails": {
"all": true
    },
    ...
  }
}

该接口设计用于获取并显示用户自己频道的盈利数据。研究员发现，它实际上也能获取其他频道的元数据，尽管可用的数据字段（mask）非常有限。如果尝试请求任何对无权访问的频道敏感的字段，API会返回“权限被拒绝”的错误。

关键发现：两个隐藏参数浮出水面

然而，当使用 req2proto 工具解析此API端点时，研究员意外发现了两个未在常规请求中使用的隐藏参数。

从生成的结构定义中，可以看到 GetCreatorChannelsRequest 消息体包含 critical_read 和 include_suspended 这两个参数。

message GetCreatorChannelsRequest {
  InnerTubeContext context = 1;
  string channel_ids = 2;
  CreatorChannelMask mask = 4;
  DelegationContext delegation_context = 5;
  bool critical_read = 6; // ???
  bool include_suspended = 7; // ???
}

测试发现，启用 criticalRead 参数似乎没有带来变化，但 include_suspended 参数的发现却意义重大。当设置 includeSuspended: true 时，响应中会返回一个通常无法获取的字段—— contentOwnerAssociation（内容所有者关联信息）。

那么，“内容所有者关联”到底是什么？

解析YouTube Content ID系统

在YouTube生态中，存在一种特殊的“内容管理者”（Content Manager）账户，仅授予少数受信任的大型版权方。这类账户可以将音视频作为资产上传至Content ID（内容识别）系统，自动对全网包含相同内容的视频发起版权主张并实现货币化。

图3：YouTube内容管理器（Content Manager）后台界面。

同时，YouTube也为三百万已开启收益的创作者提供了简化版工具——“版权匹配工具”（Copyright Match Tool）。该工具只允许创作者要求下架侵权视频，但不能进行货币化。

图4：创作者可用的“版权匹配工具”界面，显示匹配到的视频。

有趣的是，这款工具的后端技术与“内容管理者”账户是相同的。一旦频道开通收益，系统会自动创建一个 CONTENT_OWNER_TYPE_IVP 类型的内容所有者账户。IVP 是“Individual Video Partnership”（个人视频合作）的缩写，即YouTube合作伙伴计划的旧称。

通过 includeSuspended 参数，攻击者可以获取到绑定至目标频道的“IVP内容所有者”的ID（contentOwnerId）。

组合利用：泄露创作者注册邮箱

这个ID有什么用？研究员发现了专为“内容管理者”设计的YouTube Content ID API。其中，contentOwners.list 接口接收内容所有者ID，并返回其“冲突通知电子邮件”（conflictNotificationEmail）。

虽然该接口看起来会验证调用者是否拥有“内容管理者”账户权限，但研究员猜测“IVP内容所有者”类型的账户或许也能调用。经测试验证，这一猜想成立。该接口成功返回的“冲突通知电子邮件”，正是频道开通收益功能时的注册邮箱！

完整的攻击链如下：

1. 第一步：通过启用 includeSuspended: true 参数，向 /get_creator_channels 接口发送请求，获取受害者的IVP内容所有者ID。
2. 第二步：利用一个已开启收益的YouTube频道关联的Google账户（拥有IVP身份），调用Content ID API的 contentOwners.list 接口，获取与该ID关联的“冲突通知电子邮件”。
3. 第三步：成功获取目标创作者的隐私邮箱地址。

这个漏洞本质上是一种安全测试中的权限绕过和信息泄露组合漏洞。

漏洞时间线与奖励

• 2024-12-12 - 漏洞报告提交给Google。
• 2024-12-17 - Google确认漏洞存在并给予积极评价。
• 2025-01-21 - 漏洞评审小组最初奖励 $13,337，理由为“绕过重要安全控制导致PII泄露”。
• 2025-01-23 - 因漏洞存在于最高级别（Tier 1）域名 (studio.youtube.com)，涉及特别敏感数据，评审小组追加奖励 $6,663。
• 2025-02-21 - Google确认问题已修复。
• 2025-03-13 - 漏洞报告被公开披露。

总计奖金：$20,000

额外发现：隐藏参数的另一种发现方式

实际上，includeSuspended 参数并非只能通过暴力破解发现。研究员发现，通过特定的方式获取YouTube InnerTube API的发现文档（Discovery Document），也能在其中找到该参数的定义。

他们通过发送带有 X-Http-Method-Override: GET 请求头的POST请求，绕过了对直接GET方法的限制，成功获取了内部API文档。

POST /$discovery/rest HTTP/2
Host: youtubei.googleapis.com
X-Http-Method-Override: GET

在返回的JSON文档中搜索“GetCreatorChannelsRequest”，即可找到 includeSuspended 的明文定义。

（更新：在此漏洞披露后，相关环境的发现文档已被移除。）

此次漏洞挖掘过程展示了深入研究API行为、分析非常规响应以及连接不同系统权限点的重要性。对于开发者而言，这提醒了在设计和测试API时，需要彻底审查所有参数的有效性检查与权限边界。更多深入的技术探讨和实践分享，欢迎关注云栈社区的相关板块。

原文链接：https://brutecat.com/articles/youtube-creator-emails