写在前面的话
在最近的一次安全测试过程中，我对Google的应用程序“Richmedia Studio”进行了安全测试，即Google的一个营销活动管理平台。在这篇文章中，我将跟大家分享我在Google Rich Media中发现的几个安全漏洞。
第一个挑战：访问系统
虽然这并不是什么安全问题，但我仍然觉得很有意思，因为从这里才是我们打开Google Rich Media攻击面的第一步。如果你的账户里面没有配置并启用该功能的话，你是没有办法看到这个功能的。其实它并不是一个“未授权”的页面，我们只是被网站重定向到其他地方了，不信你可以尝试访问一下https://www.google.com/doubleclick/studio。这一点很关键，因为一开始我都没发现过这个应用程序，即使我花了大量时间去搜索Google的系统。
如果你想访问这个系统，你需要点击【这里】去填写一个表格，如果Google授权你访问的话，你将收到一封邀请邮件，点击之后你就可以访问这个系统了。
到处看看
这是什么？Richmedia studio?据我所知，，该平台主要用于管理在线广告活动，以及与广告商的关系。角色管理系统允许管理员创建新的活动并将媒体（如HTML页面、视频、图像等）上传到这些活动中。管理员可以给不同的广告客户访问活动，以及通过QA管理它（所有通过权限管理）和留下评论等等。因为我不太了解营销活动的流程，所以我不确定我对这个平台具体功能的定义是否准确。
第一个漏洞：访问其他用户的媒体资源（500美金漏洞奖励）
我开始研究的是其媒体资源上传功能，我希望看到与大多数谷歌应用程序相同的机制，上传的文件存储在用户的谷歌驱动器下，并通过一个带有长随机ID的临时“googleusercontent”链接公开。但事实并非如此，在Google Rich Media中，文件会上传到一个不同的域名-“s0.2mdn.net”。样本链接如下:
https://s0.2mdn.net/preview/CgkIARCom4rX5i4SGQCkoPPIITT873VA4lA-bButtVLChPwsXnU/ads/richmedia/studio/60019864/60019864_20201004010909357_xsspng.png
将文件托管在一个单独的（非“google”）域上会引发授权问题，因为浏览器不持有该域的cookies（当然，可以通过其他方式解决授权问题），而且尝试从匿名浏览器访问示例上传文件时，确实表明不需要授权。然而，这本身并不是一个真正的问题。这种联系是复杂的，不可能可以通过暴力破解或猜解攻击来拿到资源链接。但我们先来看看这个链接，访问之后，一个“预览”按钮出现在了我们的眼前。这是存储文件的实际路径，还是仅仅指向从实际源生成的“预览”的链接？
于是乎，我又上传了另一个文件，然后仔细分析了网络请求，我发现我怀疑的是对的。在一个单独的HTTP响应中，指向该文件的直接链接（而不是它的“预览”）被返回到浏览器。这个链接看起来简单得多：
http://s0.2mdn.net/ads/richmedia/studio/pv2/61580927/20201004040915088/xsspng.png
这些直接链接也可以在没有身份验证的情况下访问，并且可以由攻击者生成（前8位数字只是可以从studio应用程序枚举的商家ID，后8位数字由上载日期和短随机数组成）。
所以这里我们有一个清晰的IDOR-一个到另一个用户文件的可猜测的链接，而且没有任何身份验证。
我已经将该漏洞上报给了Google团队，并拿到了500美元漏洞奖励。
第二个漏洞：访问其他用户的活动（5000美元漏洞奖励）
说实话，这个太简单了，我都没想到。还记得我之前提到过的一个角色管理系统吗？你可以在这里创建一个账户，而无需访问QA仪表盘。事实上，如果您创建这样一个用户，那么仪表盘看起来会不太一样。管理员仪表盘界面如下：
受限账号界面如下：
如果我试图使用受限账号访问SQ页面的话，会怎么样呢，结果着实令人惊讶：
我不仅可以访问与我的用户相关的活动的QA页面，还可以看到所有活动，所有帐户！
我已经将该漏洞上报给了Google团队，并拿到了5000美元漏洞奖励。
第三个漏洞：GWT
Google Rich Media使用了GWT来处理其API请求。我在Google系统中发现的第一个问题就是GWT的授权问题。当我再次研究文件上传过程时，我将注意力放在了GWT请求上。我查看了检索文件下载URL的HTTP请求（与我们之前看到的长而复杂的链接相同），并注意到一些奇怪的字符串会被作为HTTP POST正文的一部分发送：
7|0|8|https://www.google.com/doubleclick/studio/gwt/|9DB073B0A4AFE75F8679003264944EE5|com.google.ads.api.gwt.rpc.client.BatchedInvocationService|invoke|com.google.ads.api.gwt.rpc.client.BatchedInvocationRequest/2983766987|com.google.ads.richmedia.studio.ui.common.grubby.client.BatchedInvocationRequestHeaderImpl/3117963532|java.util.ArrayList/4159755760|com.google.ads.richmedia.studio.service.CreativeServiceGwt$GetDownloadArchiveUrlRequest/1562479252|1|2|3|4|1|5|5|6|0|7|1|8|DlQXE|DlQWU|
仔细研究，你就会发现它很容易破解。最后的两个字符串“DlQXE”和“DlQWU”引起了我的注意—它们似乎是表示我实际要访问的文件的字符串。在系统中，很明显这些字符串实际上是表示系统中特定活动的ID。
没错，-我作为一个不同的用户登录并获得了另一对ID。然后我尝试在第一个用户的cookies中使用这个ID，并且能够获得第二个用户文件的URL链接。我运行了一个脚本来猜测相似的ID，并很快找到了更多有效的ID，即指向更多属于其他用户的文件。
我已经将该漏洞上报给了Google团队，又拿到了500美元漏洞奖励。
第四第五个漏洞
我现在已经非常兴奋了，而且我仍然在围绕该系统的授权机制进行研究，感觉它应该是“漏洞百出”的。果然，我又发现了一个问题：
Google的团队似乎也同意我的观点，也许Google Rich Media的授权机制确实应该好好调整调整了。
总结
研究几天之后，我脑子里想的已经不是授权的问题了，而实最初的目标应用程序发现。我之前肯定见到过https://www.google.com/doubleclick/studio/这个链接，但由于我没有权限的系统，我只是不知道它的存在。还有多少这样的应用在暗中潜伏？确实有些值得思考的东西；）