那是一个办公室里的悠闲下午。午饭后，我坐在桌前，在 Google Slides 上准备演讲的幻灯片。搞定幻灯片后，我点击了演讲者视图来预览它们。活动时，我想要进行现场问答环节和观众互动，于是上网查了一下 Google Slides 是否有这样的功能。这时我找到了观众工具。要启用观众工具，你需要进入演讲者视图，点击观众工具，然后点击“启动”。
一旦开始演示，观众就可以通过这个链接在你讲解时提问题。
出于好奇，我复制了链接，用Chrome的隐身模式打开，看看观众是怎么提问的。任何人都可以无需登录提问！提问框的用户界面看起来有点老旧，我开始怀疑这可能有bug。总觉得哪里不对劲，于是我决定仔细看看。
没有丝毫耽搁，我启动并运行了Burp Suite并开始测试。我发现每次有人提问时，POST请求中都会包含一个唯一的clientId。所以每个评论都有一个唯一的clientId。这时我突然想到——这可能是一个潜在的安全漏洞。
POST /presentation/d/e/2QANgcCBH8YIx_f5yfCz0l5len6p5BDFsiROx_rcqbOqYgcByotn7pOpaS3kXb3YYffwepoOXCyzanE8ZCIw/submitquestion?includes_info_params=1 HTTP/1.1
Host: docs.google.com
Cookie:
Content-Length: 84
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Accept: */*
Origin: https://docs.google.com
Referer: https://docs.google.com/presentation/d/e/2QANgcCBH8YIx_f5yfCz0l5len6p5BDFsiROx_rcqbOqYgcByotn7pOpaS3kXb3YYffwepoOXCyzanE8ZCIw/askquestion?seriesId=d90df436-a253-48a1-8aea-bf5c19761447
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: keep-alive
seriesId=d90df436-a253-48a1-8aea-bf5c19761447&clientId=e5j7slqfku2&questionText=问题文本=试试
当有人点击这个链接时，所有问题都会加载，并为每个评论分配一个不同的 clientId。
然后我立刻明白这里可能存在什么类型的bug。我登录了两个不同的账户，并从账户-1提交了一个名为“Test”的问题。然后，我使用另一个浏览器中的账户-2复制了账户-1评论中的clientId。在账户-2试图提交问题时拦截请求，并将clientId替换为账户-1的clientId。
结果是？账号-1提交的问题被账号-2的操作修改了。这验证了我的猜想。更让人担心的是，甚至可以无需登录就利用这个漏洞。
这时候我有点惊讶又有点震惊，反复测试看看是不是我哪里出了错。多次测试后，我确定这确实是一个真正的bug。
而且立即报告了谷歌。让我没想到的是，到了第二天，该公司关闭了报告，表示安全风险很小。
但我很清楚这个漏洞的影响：不需要任何用户交互就能利用它，也不需要猜测或暴力破解clientIds。应用程序本身提供了clientId。我礼貌地重新强调了我的有效观点。Google 重新打开了这个问题并确认了。然而，在十天后，报告又被关闭了，理由是，由于“猜测”clientId的因素，安全风险仍然被认为很低。
这时我有点失望。谷歌的安全团队没有充分测试这个漏洞，或者他们没有看我提供的 poc 视频。因为根本不需要猜测 clientId，这个 clientId 是由应用程序自动加载的。我再次清楚地说明了一次，并展示了攻击者如何轻松地提取这个 clientId。最后，谷歌的安全团队自己触发了这个漏洞，承认了这个漏洞的影响，并在我提交的 S2 严重级别中奖励了我 $3,133.70。
我在这阶段学到的一个重要教训是，在报告漏洞之前，必须非常清楚漏洞可能带来的安全影响。我非常清楚漏洞的具体安全影响，这也是为什么我能自信地与谷歌安全团队沟通，并最终成功地说服了他们。
看一下《Poc》：
谢谢你的阅读！如果喜欢的话，那就关注我，获取更多精彩内容吧：
跟我来：
@atikqur007 这是他的推特账号
共同学习，写下你的评论
评论加载中...
作者其他优质文章
