用Chrome浏览器工具发现Gmail中的DOM XSS(2)

以下是消息发送源的发送机制：

这里要提醒一下：在消息的listener和url加载端之间，存在各种各样的文件和代码，可以使用浏览器开发工具对其进行不断的调试运行，总之这是一个反复试错的过程。

有了以下了解之后，利用上述消息，我在客户端中把消息中src涉及的url参数替换成了“javascript:alert(1)” 进行测试，然而，我并没有得到一个alert弹窗，原因在于内容安全策略CSP的阻挡。

但是，好在发现该漏洞的时候，IE11 和 Edge 中没有强制CSP策略，因此在这两个浏览器中就能实现“javascript:alert(1)” 的触发实现。该漏洞原因在于未对消息源origin进行检查，一种简单的攻击场景就是，攻击者从Gmail页面中打开新标签，用postMessage方法在标签页中注入Payload。攻击者利用该方法可从受害者Gmail页面中执行任意代码，从Gmail标签中加载javascript形式的iframe，深入利用可读取并发送受害者邮件，甚至是更改受害者邮箱密码。

最后还存在一个问题：在众多的通信frame之间，要找到上述那个特别的消息确实会有些困惑，因为每个消息都会有一个所谓的频道名称（Channel Name），而由“hangouts.google.com”发送至“mail.google.com”的消息频道名称是一个6位数的数字组成，它包含在第一个交互消息中，在后续的交互消息中，“hangouts.google.com”会以该频道名称为验证，只有具备该频道名称的消息才会被“hangouts.google.com”发送处理。

所以对于攻击者来说，要想利用这种漏洞，那么首先这种随机性的频道名称（Channel Name）确实很难捉摸确定，不过2012年有安全研究者曾对这种消息机制中的随机数生成方法Math.random() 进行了利用，并在Facebook API中发现了XSS漏洞，但是，该漏洞利用需要在跨域的网页中共享随机数生成器（random generator ）的状态。

当然了，另外还可以在在Gmail标签页面的框架层次结构中加载由攻击者控制的iframe。由于iframe的跨域重定向在浏览器中的工作方式，且Gmail网页通信中的X-Frame-Options属性为SAMEORIGIN”，且消息发送参数targetOrigin的值为“*”，因此，在网络抓包中也是可以拦截到频道名称（Channel Name）的 ，那最后也能实现XSS触发利用。

反复试验后，我也没在Gmail中找到加载控制iframe的简单方法，但理论上来说，该漏洞是完全可以被攻击者进行利用的。最终我把漏洞上报给了谷歌安全团队，几天之后就收到了他们“Nice Catch”（好洞）的回复，奖励是$5000美金。谷歌的修复方式是在消息发送源的url参数加入了安全检查。另外，Chrome浏览器的开发者工具是一个非常不错的调试套件，可以支持个性化的插件开发，对Web找洞很帮助。