起因

甲方“一个人的安全部”的时候,一个研发的同事在设计一项报表功能时,因为受到邮箱的安全限制无法很好的实现,于是将情况反馈给我。说实话,我对浏览器的安全也不太了解,案头的书翻了几页就没再动过,于是对比了腾讯邮箱的做法,发现了这个xss。

背景

公司使用coremail搭建企业邮箱,开发做了一个通过邮件发送html报表的周报,但在此邮件内有链接地址。邮箱的域名是a.com,而报表中的链接是b.com,当用户打开a.com内的报表邮件,点击其中的链接;因为邮件的内容是通过iframe来加载html报表,同时coremail将iframe加入了内容安全策略(CSP)限制(sandbox=“allow-same-origin allow-popups”)。所以,点击链接虽然可以跳转到b.com,但b.com页面有js脚本,sandbox不允许执行脚本(allow-scripts),会导致新打开的链接不会加载脚本执行,效果当然也不是开发想要的效果了。

iframe-sandbox

当然通过让厂商修改iframe的sandbox属性,改为sandbox=”allow-same-origin allow-popups allow-popups-to-escape-sandbox”,即可解决这个问题,但会影响邮箱的安全性。

于是我打开qq邮箱,发现QQ邮箱并没有这个iframe策略,而是通过一个三方“云端安全检测”,对邮件内连接进行拦截,提示用户要访问的页面可能有风险。

qqmailxss

被src拒绝的“逻辑漏洞”

于是多打开了几封QQ邮件,点击了邮件内的链接,发现腾讯对智联招聘、拉钩等招聘网站的链接不会进行拦截,直接放行跳转,所以这其中是否存在一定的逻辑绕过呢?

测试过程就省略了,说结果吧,个人认为验证逻辑上还是有些问题:

当邮件内容出现链接时,点击跳转,默认QQ邮箱会进行在云端进行拦截检测。但是会有白名单机制,比如 http://www.lagou.com ,会把拉钩的招聘链接进行放行,云端安全检测检->进行跳转放行,无任何提示。

  • 现有的逻辑如下:

    https://www.lagou.com 不放行(因为https,非白名单)

    www.lagou.com 不放行(不带有http,非白名单)

    http://xss.pirogue.org 不放行(非白名单)

    等等其他域名都不放行。

但当第一行是http://www.lagou.com ,第二行的链接都会放行(除去色情或被举报的网址)。

比如:

exmple

两个链接都会进行跳转。

如果第一个是http://www.lagou.com ,第二行的网址是一个钓鱼或挂马的链接,却没有被举报。那用户便可能会受到攻击。

后来的结果是大家都知道了,被忽略了。这点我没啥争议,不是漏洞也没关系,我想一探究竟,它是通过js获取邮件内的链接,遇到点击事件就丢到三方“云端url检测”的吗?所以在审计js代码的过程中,一不小心发现了一个类ssrf漏洞。

鸡肋ssrf变身反射型xss

ssrf漏洞

  • 原功能链接:

https://mail.qq.com/cgi-bin/magurl?sid=e6tvxdAtN0XOUGoz&act=rep&url=http://x.soso.com/js/xf/xflib2.0.js

这个cgi读取到了js的内容

ssrf

  • 漏洞截图:

https://mail.qq.com/cgi-bin/magurl?sid=e6tvxdAtN0XOUGoz&act=rep&url=http://ip.qq.com/

ssrf

但此ssrf限制了域名,比如.qq.com,.soso.com,等等腾讯自己的域名。所以除非你能再挖到腾讯自己的域名下的漏洞来结合使用。可是我们还可以测试一下是否可以绕过域名的白名单机制。

反射型xss漏洞

于是我构造了如下的url,成功绕过了白名单,提交了此漏洞:

仔细看url链接里面存在一个sid,在后来的tsrc自测时发现,此sid只能是收件人的sid才能触发漏洞。额,有点self-xss的意思咯。但tsrc还是根据可能的危害程度,给了漏洞中危的回复。

结语

之前在搞一个目标的时候还挖到了一个QQ企业邮箱的存储型xss,但那个存储型xss没啥技术含量,而这个反射的起因到结果还是挺有趣的,所以迫不及待的想分享给大家。