题记：这是09年自己写的总结文章，之后多年也不搞这个了，技术显然是过时了，但我觉得思路还是有用的，算抛砖引玉吧，各位见笑 

0x00 前言

这是一篇学习总结，首先对几位未曾谋面也不知道名字的老师表示感谢，通过对你们大作的学习，使我逐渐入门开始跨入XSSer的行列，虽然我现在的水平和大师们比起来还差得太远，脚本方面的基础也不不行，但我会继续努力学习。

 

0x01 概述

曾经有一度，在N年前，我对网络安全对抗的总结就是“过滤与反过滤”，虽然现在看起来这种理解太狭隘了，不过在很大程度上过滤和突破过滤确实是很重要的手段。安全的目的就是过滤掉有害信息，保存安全的信息，而黑客的目的就是突破过滤把有害信息传递过去。无论是SQL注入、XSS、溢出等等，最最核心的东西就是突破过滤。本文主要讲针对存储型XSS过滤器的fuzz。

0x02 XSS filter：安全域边界

随着XSS攻击越来越流行，对XSS的过滤也越来越成熟，尤其是存储型XSS，由于攻击更加灵活多变，应用更加广泛，所以过滤手段也更复杂，从最早的黑名单字符串过滤，发展到现在基于语法分析的黑白名单相结合的过滤器，对攻击的难度要求也越来越高。

由于对反射型XSS的过滤相对简单，所以本文只讨论存储型XSS过滤。现在的存储型XSS过滤大多是基于HTML语法进行过滤，为什么不用简单的字符串过滤呢？这是因为HTML支持的编码方式非常多，而且要区分哪些是HTML语言哪些是文本内容也很麻烦。例如：

是要过滤的，而

是正常的内容，所以必须进行HTML语法分析。

filter另一个要考虑的问题是用户体验，一些很严格的过滤器虽然相对安全，但是对正常内容的改变太大，页面都变样了，正常用户使用起来感觉不太好。其实大多数XSS filter的漏洞并不是不能发现XSS，而是发现以后不能完全清除，在某些方面看来也是为了考虑正常用户的使用感受。

基于HTML语法分析的filter会把输入内容划分成很多不同的安全域，例如HTML标签之外的内容不过滤，是最低安全级别，在HTML之内也要划分，样式表是容易出问题的地方，要重点扫描，甚至考虑用白名单，即使在样式表内部也要划分不同的区域使用不同的扫描级别。因为不同的安全域有不同的检测方法，所以容易出问题的地方就两个安全域之间的边界，一旦边界搞错了就有可能突破过滤。

0x03 fuzzer的设计：突破边界

当一些普通的尝试无法成功突破filter，就要考虑用fuzzer。首先要设计测试模型，这也是最核心的问题。我经常想为什么fuzzing能够成功呢，一定是filter存在某些隐藏比较深的漏洞，例如前面谈过的安全域边界，所以我们设计fuzzing模型就重点对这些地方进行测试，举个例子说明一下安全域边界的问题：

其中：

expression(alert(9))

是重点扫描区域也就是最高安全级别区域，对这个区域应该过滤/* */和expression等，filter怎么确定这个区域呢？首先在div标签内找到style属性，在=后面找到""之间的内容，根据:来划分样式名称和内容，以;分隔几个样式。那么在这里=":;这些都是关键字。如果XSSer提交以下内容：

最高安全区域还应该是

expre/*"*/ssion(alert(9))

但是如果filter在划分区域的时候首先根据第一个封闭的双引号对来划分，那么就会针对下面的内容做过滤：

width:expre/*

这样显然是不正确的，因为/* */中的内容是注释，是要丢弃的内容，如果先根据第一个双引号就确定了区域边界的话，那么在绿色区域也是过滤不到expression的，就会导致过滤被绕过。所以在这里正确的确定边界的方法是找到最后一个双引号来进行封闭，如果没找到的话还要自动添加，否则又会造成高级别安全区域的扩大，扩大了并非会更安全，安全区域的扩大会引起后面的边界混乱，同样会造成漏洞。当然了，这个情况只是我想象出来的用来举例的，实际情况不太可能这么简单，这里要说明的只是区域边界对于XSS fuzzing的重要性。

因此我们设计fuzzer的时候就要在一个模版的有可能导致边界混乱的地方添入一些元素组合来作为testcase，所以第一要考虑的是确定模版，例如我们可以把

作为模版，元素填充在/**/之间。这样就有了一个简单的fuzz模型。

当然了这并不是一个好的模版，因为不够复杂，filter一般都会考虑到了。

那么在前边加点东西：

这样有两处地方填充元素，稍微复杂了一点，比第一个模版好点。我的想法是，越复杂的模版和越多的填充位置、填充元素，才越有可能跑出漏洞。但实际应用中因为我们是黑盒测试，所以还要考虑其他一些问题，例如效率、可识别性等等，这个后边再说。

有了模版，用什么样的元素进行填充，就是我们要考虑的第二个重要问题。首先边界元素肯定是要的，例如上边的例子里面的边界元素

=":;

能想到的还有

空格、<、>、</div>

等，有时候虽然看起来不可能确定错边界，但实际上filter的行为往往出人意料，这也正是fuzzing存在的意义。

除了边界元素之外还有一种要考虑的是filter过滤的元素，例如filter过滤expression，我们就把expression也当做随机填充的元素，还有/和/、onXXX()等，当filter删除或改变这些内容后就有可能会导致边界的改变。

另一个元素是不可视的特殊字符，例如\t、\r、\n、\0等等，半个UNICODE字符等。还有被filter反向解码的字符串，例如&#XX、%XX、\XX等。

最后要考虑的确定模版和元素的情况是浏览器的undocument行为，例如

会被IE正常解析。这里有两个<，而且div后面用/分隔而不是空格，某些filter可能考虑不到这样的行为，因为这样写不符合HTML语法规范。类似这样的浏览器的奇怪解析方式还有很多，去年分析过YAHOO Mail跨站的DX都会对CSS里面的不正常的url()记忆犹新吧，我挺佩服发现这种方式的那位老师的，这个的问题看起来似乎并不是仅仅是filter的问题，连IE对边界的划分都是存在问题的，当然这种问题单单对IE来说只是个小BUG而不能算漏洞，但是结合了YAHOO的filter之后却导致了XSS。

0x04 实践练习：本地fuzzing的例子

在实际进行远程黑盒fuzzing之前我们先来构造一个本地fuzzing的例子来练习一下，看看模版的构造和元素的选择能否达到预想的效果。

我选择了htmLawed作为fuzzing对象，这是一个php写的开源的HTML过滤器，有兴趣的话可以先到http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php这个网站，先手工测试一下看看能不能手工绕过它对CSS的过滤，也许大牛是可以手工XSS的，反正我试了一会没有成功，没办法，智商就只有这么多。这里我说的是上面那种例子里的样式表XSS，你可别直接输入一个<script>人家是不过滤的，因为这个filter还要加参数。

我下载了htmLawed之后，在本地做了一个测试程序：