浅谈chrome xss filter

日期: 2011年11月6日 | 标签:, | 阅读:1,352

http://hi.baidu.com/rayh4c/blog/item/828fedfef86e3a2d5c600886.html

浅谈chrome xss filter和IE 8/9 xss filter的小差异

我之前研究过IE 8/9 xss filter，把IE 8/9 xss filter每个拦截正则都提取出来研究过，深感微软在XSS上下了深功夫。

 

今天看见余弦http://evilcos.me/blog/?p=60这篇文章，以前没有看过chrome ，所以在余弦的思路上即兴测了下chrome 。

写了个简单的测试代码：

<html>
<head></head>
<body>
<?php
echo $_GET[‘a’];
?>
</body>
<script>
alert(document.getElementsByTagName(‘body’)[0].innerHTML);
</script>
</html>

我们可以看出IE和chrome 的拦截差异:

1.chrome是动态替换了节点内容，我们在BODY节点下的script顺利执行了。

2.IE直接在存在跨站脚本的节点断住了，也就是我们在BODY节点下的script无法再执行了。

 

从差异上我们也看出了点蹊跷，chrome 动态替换了script标签内的alert(1),如果对标签<>内的内容做FUZZ呢？所以我们便轻易绕过了它

 

IE 8/9 xss filter比chrome xss filter的拦截效果不止好了一大截，但我们不要忽略了一点，那就是应用和安全是一个矛盾体，IE 8/9 xss filter的安全效果也要付出误报的代价，记得前几年我还在做WEB安全测试时就经常遇到第一线的工程师抱怨IE 8/9 xss filter的误报情况，从这些综合考虑，我觉得chrome xss filter不管是拦截方式和规则都相对优雅一点，但仍有改进空间。

 

最后本文还是浅谈，要深入了解这些，需要逆向一下mshtml.dll和分析下chrome的源码。另外替余弦的《跨站之路》打下广告，期待一下，好的思路永远会启发人。

 

chrome xss filter的优雅之处

 

 

= = 上一篇坏坏的埋了个小坑。没想到这么快就被sogili发现了。

我说的chrome xss filter的优雅之处其实是chrome使用了火狐的CSP策略。

什么是CSP策略，参考  wiki.mozilla.org/Security/CSP/Specification

CSP策略是国外各路WEB安全大牛共同推荐和制订的浏览器的安全策略之一，以前黑锅也常推崇这个。

而改进空间即是chrome xss filter使用的CSP策略并未深入，同源的资源文件如果是个图片呢？

 

解析如何绕过chrome xss filter

 

之前我的两篇科普，大家应该了解了chrome xss filter的特性：

基于CSP策略拦截，即匹配到XSS的标签，对标签的内容进行处理，即

<script>内容</script>

<script src=内容></script>

src这类资源内容存在同源策略的特性，那么我们就要结合其他的WEB漏洞了，如上传图片等。

 

chrome11的xss filter存在一个老漏洞：

http://seclists.org/fulldisclosure/2011/May/490

那么这个老漏洞的真面目是什么

 

这个老漏洞是利用了chrome的标签自动修正特性

输入：<img src=”noexist” onerror=”alert(1);//

而chrome自动将内容修正为：

<img src=”noexist” onerror=”alert();//&lt;/body”>

 

如果输入什么就输出什么，这个漏洞是不会存在的。

再次叹一下应用和安全是一对矛盾体，这个在应用上出于网页兼容性的标签修正功能便毁掉了XSS防御的基础。然而安全工作者的乐趣不正在其中么，直直白白的简单漏洞没有乐趣，而这种二次漏洞乐趣自在其中。

 

最后在攻击者的角度得出结论，虽然CSP是我们的绊脚石，这个绊脚石也可以绕，但我们要硬绕的话，还是需要对<>标签里的内容进行FUZZ，还需要找出应用中对安全真正的有利的点。

 

bypass chrome xss filter再深入

 

实际上我们之前所看到的东西都是虚幻的，那些脚本都是动态渲染的，我们始终是在一个盒子里，我们来打破这个盒子，接着往下看.

 

看下面的代码，我们少了闭合了</body>标签

<html>
<head></head>
<body>
<?php
echo $_GET[‘a’];
?>
<script>
alert(document.getElementsByTagName(‘body’)[0].innerHTML);
</script>
</html>

 

程序自动修正给我们闭合了body标签，同时我们看到没闭合的IMG标签的属性值居然吃掉了下一个标签，看到这里你应该理解了，还是标签修正的问题。

 

程序是这么理解的，没有闭合的标签，onerror=后的内容全是可疑的脚本内容，需要修正。

<img src=”noexist” onerror=alert(1)<script>xxxxxxx</script>

于是修正为了

<img src=”noexist” onerror=“alert(1)//&lt;script”>xxxxxxx

 

理解了这些后，那我就爆个0DAY吧，希望有助于大家理解安全的原型：

 

假设有这么一个场景，我们的XSS输出的标签的下一个节点是一个<script>标签，还是上面的模拟代码，只是这次闭合了body标签。

<html>
<head></head>
<body>
<?php
echo $_GET[‘a’];
?>
<script>
alert(document.getElementsByTagName(‘body’)[0].innerHTML);
</script>
</body>
</html>

 

由于我没有闭合script标签，所以根据chrome xss filter的标签修正特性，它会去找下一个标签的内容，发现多出来的<script>标签进行修正，于是便诞生了0DAY，执行了我们的跨站脚本。

 

总结：

chrome xss filter的标签修正特性存在漏洞，在标签的属性值未闭合和完整的标签未闭合的特定场景下可以执行跨站脚本内容。

 

 

评论关闭。