gmail 和 google 的两个 xss 老漏洞分析
翻译作者：DM（信安之路前端安全小组成员） 原文地址：https://blog.bentkowski.info/2014/06/gmail-and-google-tale-of-two-xss-es.html
在这篇文章中，我会展示一下我在 Gmail 和 Google+ 中找到的两个 XSS 漏洞。特别是我会解释两个问题：
- 为什么我需要第二个平台去注入第一个平台；
- cookie 中的作用域的正确设置有多重要。
Gmail
Gmail 是我们最常用的的 google 服务之一，有很多不同的版本，包括基本 HTML 版本和移动版旧版。这次我要介绍的 XSS 漏洞发生在上面的两个版本中。这些版本中的功能比较简单，只能完成最基础的功能，只有基本的查看和发送邮件，但是最重要的一点是，我们可以设置标签。
举个例子，我们尝试设置一个<test>标签。
操作完成后，Gmail 会在通知中告知已对会话进行了标记。
当查看 http 会话时，我发现通知的内容实际上被放在 cookie 里。
cookie 里的 html 实体 < 和 > 吸引了我的注意力，接着我们很自然地想到这里是否能够插入自定义标签,例如 <img src=1 onerror=alert(1)>
然而这个 payload 没起作用，服务器报了 500 的错误。估计是 ">" 导致了这个错误。因为右尖括号在 cookie 里还有其他的用途。可能是 cookie 被 ">" 拆分，并且当有一个超出预期的字符传入时，服务器端会发生一些错误，所以我们需要再修改下 payload，去掉了右尖括号：
这次成功了，alert 生效了，我在 mail.google.com 上找到了一个 xss 漏洞。
但现在仍然存在一个主要的问题。为了能够利用这个漏洞，我需要能够在受害者的浏览器中去设置任意 cookie。这通常是不可能的，需要另一个满足下面条件之一漏洞：
1、http 响应分割
2、无限制的设置 cookie：
https://miki.it/blog/2013/9/15/xsrf-cookie-setting-google/
3、另一个 xss 漏洞
前俩个条件非常难以满足，所以我们只关注第三个。还记得 Set-cookie 包含那些属性吗？
其中之一便是 domain。所以当你发送一个消息头时:
Set-Cookie: Test= test;
Domain= .google.com
......你创建了一个 cookie, 而这个 cookie 会被发送到 Google.com 的任何子域。因此，我需要在任意其他 Google 子域上找到另一个 xss 漏洞，并使用它去设置一个 cookie 去注入 Gmail。Google 有大量的服务，所以这应该不难;)
Google+
我十分幸运地在 Google+ 上找到了另一个 xss 漏洞。就像在 Gmail 中一样，这个漏洞存在于移动端而不是主版本。
这一次，我发现在上传照片时，很容易受到攻击。我注意到在上传请求中有两个很明显的 base64 的 http 参数:puSuccessResponse和puFailureResponse。
解码后：
解码后的结果包含了上传结束后的服务器响应的 html 代码。puSuccessResponse会在一切正常时运行，而puFailureResponse则是在失败时运行。更有趣的是这个请求包含CSRF token，当token不正确时，服务器会报 500 错误，但是puFailureResponse仍然会被应用！
做一个简单的测试，让我们用alert(1)来检查一下：
现在我们将操作组合起来。
代码如下:
<html>
<body>
<form action="https://plus.google.com/_/upload/app/basic/photos?cbp=&cid=5&soc-app=115&soc-platform=1"method="POST"enctype="multipart/form-data">
<input type="hidden"name="puSuccessResponse"value="aGVq"/>
<input type="hidden"name="puFailureResponse"value="PHNjcmlwdD4KYWxlcnQoIkR1ZGUsIHlvdSdyZSBYU1MtZWQgb24gIitkb2N1bWVudC5kb21haW4pOwpkb2N1bWVudC5jb29raWU9IkdNQUlMX05PVEk9dGwxPjxpbWcrc3JjJTNkMStvbmVycm9yJTNkJTIyYWxlcnQoJ0FuZCtub3crb24rJyUyYmRvY3VtZW50LmRvbWFpbiklMjIreDsgIERvbWFpbj0uZ29vZ2xlLmNvbTsgUGF0aD0vIjsKZG9jdW1lbnQubG9jYXRpb24gPSAiaHR0cHM6Ly9tYWlsLmdvb2dsZS5jb20vbWFpbC94LyI7ICAgCjwvc2NyaXB0PiAg"/>
<input type="submit"value="Double XSS!"/>
</form>
</body>
</html>puSuccessResponse被解码为:
<script>
alert("Dude, you're XSS-ed on "+document.domain);
document.cookie="GMAIL_NOTI=tl1><img+src=1+onerror="alert('And+now+on+'+document.domain)"+x; Domain=.google.com; Path=/";
document.location="https://mail.google.com/mail/x/";
</script> 让我们看看发生了什么：
1、系统会显示 plus.google.com 上的弹窗
2、cookie GMAIL_NOTI中被设置了 xss 代码，mail.google.com 会读取这条 cookie 从而被 xss 攻击
3、用户会立即重定向到 mail.google.com 从而被 xss 攻击
您可以在下面的视频中看到结果：
这两个漏洞已经在 2014 年 3 月报告给了 Google，并且已经被修复。非常感谢 Google 安全团队的，这是一个锻炼技能的好方法。
总结
这是一篇 2014 年的文章，虽然文中的平台已经改进了，但是技术的本质没有变化。mail.google.com 本身是没有 xss 漏洞的，但读取了从 plus.google.com 传来的 cookie 时，并没有进行过滤，安全问题就由此产生了。
cookie 中的数据一般是由服务器分发的，所以在开发中很难想到 cookie 中的数据也是不安全的。这里其实有两个办法来解决这个问题：
1、对 cookie 的数据进行过滤；
2、正确设置 cookie 的作用域。
两个方法如果实施了任意一个都可以防止 xss 的产生。从现在来看，浏览器的的存储空间不仅仅有 cookie，还有 sessionStorage、localStorage、IndexedDB。从这些来源的数据在处理时也需要被谨慎考虑。