沉睡的存储型XSS漏洞竟然唤醒了$5000赏金

亲爱的读者们：

在本文中，我将为大家分享自己在GoogleCloud Console中挖掘存储型XSS漏洞的故事。当然，在我看来，之所以能够挖到这个漏洞，有一定的运气成分在里面。有些读者可能还记得我在发现Google Payments的一个漏洞后发给Frans Rosén的推文：

事实证明，当我将这些“不太奏效”的XSSpayload保存到自己的Google帐户之后，竟然有一个被触发了。这真是出乎我的意料：我刚开始测试这些payload的时候，没有一个被触发执行；谁知道无意中将它们存储到自己账户后，竟然有一个“大发神威”！当然，读者看到这些可能有些摸不着头脑，所以，还是让我们从头说起吧。

如您所知，Google通常会为自家的云服务提供60天的免费试用期，只要期间产生的费用不超过300美元就行，为了得到这份免费的午餐，用户只需输入（正确的）付款信息，以证明自己不是机器人即可。所以，几个星期前，我就申请了一个试用账户，并在所有可以接受用户输入的地方尝试各种XSS payload……谁知道它竟然没有任何反应，这说明所有尝试都失败了。我想大家都经历过这种情况，对吧？好吧，大约两个月后，我收到了谷歌的通知，说免费试用到期了。为了避免产生帐单，我迅速登录帐户，并删除了自己的项目，该项目名为 „> <img src = x on error = ja vasc ript: alert (1);……就在这时，只听砰的一声，我的payload竟然被执行了！

事实证明，当项目被撤销时，谷歌并没有对相关的错误消息进行安全过滤。精明的读者可能会问，为什么没有将其归类为Self-XSS漏洞呢？这是因为这个漏洞能够带来更严重的安全威胁：Google云平台可以供多个用户使用；如果用户创建了一个带有恶意XSS payload的项目，那么，该payload就可能被该项目的管理者用来执行恶意ja vasc ript代码（如果他们删除该项目的话，就可能出现这种情况）。

为了帮助不熟悉XSS漏洞的读者了解其中缘由，我们将对上面的代码进行详细的解读。其中，第一个引号和尖括号，?>“，用于结束前面的HTML标记，这样一来，我注入的脚本标记就能生效了，对于这个POC来说，我直接使用了img src = x payload。由于x并非一个有效的URL，所以会立即失败，并导致404 HTTP响应，然后，就可以调用on事件来执行前端函数了。不过，这里要感谢HackerOne团队成员@jobert的提示，这可能会返回2xx状态码或重定向到2xx状态码的3xx状态码，如果出现这种情况的话，payload将无法启动。在我自己的测试过程中，我只是添加了一个函数alert来创建弹出窗口，但是恶意用户可能会使用cookie窃取器或浏览器漏洞利用框架(BEEF)来让这个漏洞升级（关于这一点，我想不用提醒Google，他们也能想到）。

以下是我给Google VRP发送的PoC演示视频：

https://youtu.be/AlNkfKReH_I

到这里，故事就讲完了。

原文地址：https://blog.it-securityguard.com/bugbounty-sleeping-stored-google-xss-awakens-a-5000-bounty/