猫咪视频
有谁会不喜欢猫咪视频？
Google 幻灯片有一个巧妙的功能，可让将 YouTube 视频添加到演示文稿中。只需打开视频选择器，查找你最喜欢的剪辑，然后将其添加到幻灯片上即可。
出现的是一个 iframe，链接到 www.youtube.com/embed/{VIDEOID} ，然后播放的是一段可爱的猫咪视频。但除了播放视频之外，我们还能做些其它事情吗？
查看网络流量，似乎将视频添加到幻灯片上会向幻灯片发送 videoid，然后使用该 videoid 构建的 iframe 嵌入 URL。
我们无法控制完整的 URL，只能控制 videoid 部分。
这里要尝试显然是路径遍历 – 如果我们将 videoid 更改为../ ，完整的 url 将会是 www.youtube.com/embed/../ ，然后会变成www.youtube.com/ ，从而进入 YouTube 主页。
让我们来试试看！
居然成功了！我们在幻灯片的 iframe 中拥有了 YouTube 主页（或者说是一个拥有了 YouTube 主页的错误页面）。
YouTube 与现在大多数网络应用程序一样，不允许对其大部分页面进行框架，以防点击劫持攻击。
当然， /embed/页面是一个例外，因为该页面能够嵌入到其他网站上，那么我们可以构建其它有趣的 www.youtube.com 页面吗？
通过研究，在/s/上发现了一堆可框架的资源。我们可以在演示文稿中添加 YouTube 表情符号和 css/js 源代码等内容！
不幸的是，它现在看起来没啥用。
重定向
开放重定向是一种“漏洞”，可以将用户重定向到任意其它页面。例如，访问 google.com/url?q=https://lyra.horse 会将你带到lyra.horse 网站。
重定向很少被认为是真正的漏洞，因为它们的影响非常有限。（毕竟该漏洞只会从一个页面重定向到另一个页面）
然而，由于我们被困在youtube.com上的 iframe 中，此时的开放重定向就非常有用了。
能够将幻灯片的 iframe 导航到我们指定的网站一定是件有趣的事。接下来就让我来找一个吧！
第一个明显的地方是网站周围的外部链接 – 例如视频描述和评论中的链接。
事实上，单击视频描述中的链接会通过特殊的/redirect 端点进行重定向：
https://www.youtube.com/redirect?event=video_description&redir_token=QUFFLUhqbjdTaFRBeHRfSW95bkJDVmRGcl96VXV6MkNmd3xBQ3Jtc0tuOVg2b2ZsQVV6V3hpaUJfdXB0UWY2Z1A1bE1sUjlQeHZ4WlVYSzNVUXZBcUF0RFYzNHhLazVUUVFQM1Y5N3VGZEV4bmtCVWhmYXRwY05KWlEyY0w3ZHBBdDY5SEtBa1hpQXBkalpqT3liYzFqYVZxSQ&q=https%3A%2F%2Flyra.horse%2F&v=tbYxAFHnzG0重定向现在可以工作，但会发现它有一个redir_token参数 – 该参数是某种对你的会话唯一的重定向令牌。
如果其他人打开相同的链接，他们会看到如下页面：
说服他人点击这样的页面是很困难的 – 即便如此，我们仍然无法在跨源 iframe 中使用它，因为它的x-frame-options标头设置为SAMEORIGIN(同源)。
寻找开放重定向的下一个明显位置通常是网站的身份验证流程 – 通常网站希望将你返回到登录前所在的同一页面。
对于 YouTube 来说也没有什么不同，登录 Google 帐户会将你带回原来所在的页面，这是通过/signin 端点实现的：
https://www.youtube.com/signin?action_handle_signin=true&app=desktop&hl=en&next=https%3A%2F%2Fwww.youtube.com%2F&feature=passive&hl=en该端点会在不使用验证令牌的情况下进行重定向！我们只需在下一个参数中指定我们选择的 url，就会起作用。让我们再次尝试。
看来它依然不允许进行开放重定向，接下来尝试 google.com – 仍然是同样的错误。尝试 youtube.com ，再次出现同样的错误…
然后我们似乎忘记了子域，研究人员很快就发现可以与任何 YouTube 子域一起使用的重定向 – music.youtube.com 和 admin.youtube.com都有效！
虽然仍停留在 YouTube 的域名上，但至少现在有了更多的攻击面可以使用。
重新重定向
不过， /signin 重定向并非唯一一个 – 在不同的 YouTube 子域上还存在另一个重定向：
https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=&continue=https%3A%2F%2Fwww.google.com&tcc=1&dbus=EE这似乎是用于谷歌帐户登录的，例如，如果你登录 google.ee ，将被重定向到 accounts.google.com 和 accounts.youtube.com 以更新这两个域上的cookie。
稍微尝试了发现虽然它依然不是完全开放的重定向，但它确实允许在continue 参数中使用各种 Google 自己的域，包括 Docs 等服务。
如果我们可以将 iframe 重定向到 docs.google.com，它将带来更多可能性。
Google 文档的构建方式是，其大多数页面将x-frame-options标头设置为SAMEORIGIN ，这意味着我们不应该在其他网站上为这些页面设置框架。
然而，如果有了这样的重定向，我们就可以在 Slides 中使用同源 iframe，从而允许我们构建不允许的页面，并对它们做一些很酷的事情！
尝试将之前的路径遍历/signin 重定向链接到新的accounts.youtube.com 重定向，看看是否可以使其在自身中嵌入文档页面。
太棒了！ 文档里面添加了文档！
现在要怎么做？
虽然在文档中添加了文档，但实际上可以用它做任何有用的事情吗？
找到的唯一有趣的交互是删除文档，而且无论如何你都可以从回收站中恢复它，因此我们需要找到对文档领域更有影响力的东西。
你可能认为文档编辑页面本身很有用，但这些页面已经有了适当的保护，因为它们已经（有意）可以在外部网站上框架。
如果页面检测到它位于 iframe 内，它将禁用许多危险功能，例如文档的共享选项。
这部分实际上是研究人员花了最长的时间才弄清楚的，在浏览 Wayback Machine 并尝试各种 Google dorks，研究人员发现了一堆曾经有用的旧端点，但现在只能重定向到我们无法构建的 Google Drive。
经过一个又一个的链接，研究人员最终偶然发现了这个网址：docs.google.com/file/d/{ID}/edit 。该页面允许我们预览 Google 云端硬盘文件并对其执行操作（例如共享），与之前找到的其他链接不同，它保留在 docs.google.com 域上，而不是重定向到云端硬盘。
它不仅适用于云端硬盘文件，还适用于文件夹和其他此类实体（例如 Google 协作平台页面），甚至可以用它打开云端硬盘的“Root”文件夹！
该页面有一个共享按钮，即使在 iframe 内也保持启用状态，如果我们可以诱骗某人单击“Share”按钮，输入我们的电子邮件并更改某些重要文件夹的权限，我们将获得对其的访问权限。
我们可以这么做吗？
我们真的可以欺骗某人执行所有这些操作吗？也许，如果我们足够努力的话，但即使我们拥有所有的 iframe 和点击劫持能力，也需要花费很多功夫才能说服某人去做这一切。
VRP 小组不会对如此依赖社会工程留下深刻的印象，我们必须找到一种方法使其更具说服力 – 理想情况下将其压缩为只需单击一下即可。
在思考改进攻击的方法时，研究人员想起了 Drive 中的一个功能，可以让你请求访问其他人的文档，这样做会发送一封带有很酷的小按钮的电子邮件，可以立即拥有管理权限。
该电子邮件中的按钮链接到 https://drive.google.com/drive/folders/{ID}?usp=sharing_esp&userstoinvite=lyra.horse@gmail.com&sharingaction=manageaccess&role=writer&ts=66e724ba ，打开后会弹出打开带有请求通知的共享对话框。
当然，这是一个云端硬盘链接，而不是文档链接，当尝试将所有查询参数复制到文档链接时，这似乎成功了！
在当前状态下，该页面需要我们单击两次才能完成攻击 – 首先单击“Review”标签，然后单击“share”按钮。这已经相当不错了，但研究人员仍希望将整个攻击简化为只需单击一下即可。
研究人员拿出 DevTools 并开始深入研究页面的 JavaScript，以了解如何处理查询参数，作为简单的测试，可以从 userstoinvite 查询参数开始。
哇！？居然无意中发现了完美的共享对话框 URL，由于某些原因，省略了所有其他查询参数后，共享对话框就会自动填写查询参数中的电子邮件字段，并默认提供编辑器权限。
在这里所需要做的几乎就是说服某人单击“Send”按钮了！
重新重新定向
将所有攻击组合在一起：
-
首先获取文档邀请网址:
https://docs.google.com/file/d/1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL/edit?userstoinvite=lyra.horse@gmail.com -
然后将其放入accounts.youtube.com 重定向中:
https://accounts.youtube.com/accounts/SetSID?continue=https%3A%2F%2Fdocs.google.com%2Ffile%2Fd%2F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%2Fedit%3Fuserstoinvite%3Dlyra.horse%40gmail.com -
然后将其放入 youtube.com/signin 重定向中：
- 最后，将其转换为可以嵌入到幻灯片中的“videoid”路径：
../signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.com%252Fa%252Fa%252Ffile%252Fd%252F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%252Fedit%253Fuserstoinvite%253Dlyra.horse%2540gmail.com一切就绪，把它扔进我们的幻灯片里……
居然失败？
Docs似乎有某种缓解措施，防止我们在IFRAME中对文件页面使用跨站点重定向，更准确地说，它会检查SEC-FETCH-Dest和SEC-Fetch-Site标头，如果它们分别设置为iframe和cross-site，将返回403。
通过与谷歌的几位安全人员聊天，这似乎是防止服务器端跨源框架的某种缓解措施。
目前还不完全确定它在什么威胁情况下有用，但它的原理是，iframe 可以通过 Sec-Fetch-Site 头信息判断是否在同源页面上。在跨源页面上，即使 iframe 中的重定向是同源的，header 也会始终设置为跨站点。
当然，可以使用 JavaScript 等在客户端更可靠地检测到这一点，但标头是服务器在发送响应之前判断的唯一方式。
服务器端检测的一个副作用是，即使我们的两个框架都是同源的，iframe 内的跨源重定向仍然会以跨站点标头结束，为了绕过这个问题，我们需要在 iframe 内部执行同源重定向。
简单来说，就是：
account.youtube.com（跨网站）→ docs.google.com/file/d/…/edit (403)
为了绕过这个问题，我们想要链接一个像下面这样的重定向：
accounts.youtube.com (cross-site) → docs.google.com/??? (same-origin) → docs.google.com/file/d/…/edit (200)
理论上应该是有效的！但我们必须找到适合中间部分的东西，幸运的是，研究人员之前在谷歌搜索中已经发现了类似的东西。
似乎有一个旧的 GSuite URL 格式 docs.google.com/a/<domain>/…，它可能在几年前做了一些有用的事情，但现在当你打开 URL 时它就会消失。
如果你是未登录状态，则必须找到一些可用的 URL 来使用，例如 /a/wyo.gov/7 ，但如果你已登录的话，甚至可以执行 /a/a/。
下面有几个可供尝试的示例 URL。
无论你的登录状态如何，操作都是有效的：
https://docs.google.com/a/wyo.gov/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit
下面则需要登录 Google 帐户：
https://docs.google.com/a/a/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit
两者最终都会重定向到：https://docs.google.com/file/d/10LlimFowOJ_noDrJsv4CnRgU8XoUKRAa6YjTeJFrs70/edit
弄清楚这一点后，让我们将 /a/a/ 内容放入之前的“videoid”中：
../signin?next=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID%3Fcontinue%3Dhttps%3A%2F%2Fdocs.google.com%252Ffile%252Fd%252F1sHy3aQXsIlnOCj-mBFxQ0ZXm4TzjjfFL%252Fedit%253Fuserstoinvite%253Dlyra.horse%2540gmail.com
成功！
收尾工作
通过演示文稿中的共享对话框，我们现在所需要做的就是用其他内容覆盖它，使其看起来更加美观。
由于我们在这里需要做的就是让某人单击“发送”按钮，因此让我们的演示看起来像 Google Forms。
完成！这下看起来更像一个 Google 表单页面，但它在下面的共享对话框中为“Send”按钮提供了一个“切口”。如果单击，它将立即与我们指定的任意电子邮件共享目标文件/文件夹的编辑器权限。
要将此攻击发送给某人，我们可以将幻灯片 URL 中的 /edit 替换为 /present，以将其打开并直接“播放”幻灯片。
就这样，一键点击劫持攻击将 Google Slides YouTube 嵌入路径遍历链接到三个单独的重定向，从而获得了云端硬盘文件/文件夹的编辑器访问权限！
该漏洞于 2024 年 7 月 1 日向 Google 报告，Google 于同一天对该漏洞进行了分类和确认！
10天后，即7月11日，VRP小组授予白帽小哥3133.70美元外加1000美元的赏金奖金，总计4133.70美元。真香～
以上内容由骨哥翻译并整理。
原文：https://lyra.horse/blog/2024/09/using-youtube-to-steal-your-files
