```
最高安全区域还应该是
```text
expre/*"*/ssion(alert(9))
```
但是如果filter在划分区域的时候首先根据第一个封闭的双引号对来划分，那么就会针对下面的内容做过滤：
```text
width:expre/*
```
这样显然是不正确的，因为/* */中的内容是注释，是要丢弃的内容，如果先根据第一个双引号就确定了区域边界的话，那么在绿色区域也是过滤不到expression的，就会导致过滤被绕过。所以在这里正确的确定边界的方法是找到最后一个双引号来进行封闭，如果没找到的话还要自动添加，否则又会造成高级别安全区域的扩大，扩大了并非会更安全，安全区域的扩大会引起后面的边界混乱，同样会造成漏洞。当然了，这个情况只是我想象出来的用来举例的，实际情况不太可能这么简单，这里要说明的只是区域边界对于XSS fuzzing的重要性。
因此我们设计fuzzer的时候就要在一个模版的有可能导致边界混乱的地方添入一些元素组合来作为testcase，所以第一要考虑的是确定模版，例如我们可以把
```text
#!html
```
作为模版，元素填充在/**/之间。这样就有了一个简单的fuzz模型。
当然了这并不是一个好的模版，因为不够复杂，filter一般都会考虑到了。
那么在前边加点东西：
```text
#!html
```
这样有两处地方填充元素，稍微复杂了一点，比第一个模版好点。我的想法是，越复杂的模版和越多的填充位置、填充元素，才越有可能跑出漏洞。但实际应用中因为我们是黑盒测试，所以还要考虑其他一些问题，例如效率、可识别性等等，这个后边再说。
有了模版，用什么样的元素进行填充，就是我们要考虑的第二个重要问题。首先边界元素肯定是要的，例如上边的例子里面的边界元素
```text
=":;
```
能想到的还有
```text
空格、<、>、
```
等，有时候虽然看起来不可能确定错边界，但实际上filter的行为往往出人意料，这也正是fuzzing存在的意义。
除了边界元素之外还有一种要考虑的是filter过滤的元素，例如filter过滤expression，我们就把expression也当做随机填充的元素，还有/和/、onXXX()等，当filter删除或改变这些内容后就有可能会导致边界的改变。
另一个元素是不可视的特殊字符，例如\t、\r、\n、\0等等，半个UNICODE字符等。还有被filter反向解码的字符串，例如&#XX、%XX、\XX等。
最后要考虑的确定模版和元素的情况是浏览器的undocument行为，例如
```text
#!html <
```
会被IE正常解析。这里有两个<，而且div后面用/分隔而不是空格，某些filter可能考虑不到这样的行为，因为这样写不符合HTML语法规范。类似这样的浏览器的奇怪解析方式还有很多，去年分析过YAHOO Mail跨站的DX都会对CSS里面的不正常的url()记忆犹新吧，我挺佩服发现这种方式的那位老师的，这个的问题看起来似乎并不是仅仅是filter的问题，连IE对边界的划分都是存在问题的，当然这种问题单单对IE来说只是个小BUG而不能算漏洞，但是结合了YAHOO的filter之后却导致了XSS。
## 0x04 实践练习：本地fuzzing的例子
在实际进行远程黑盒fuzzing之前我们先来构造一个本地fuzzing的例子来练习一下，看看模版的构造和元素的选择能否达到预想的效果。
我选择了[htmLawed](http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/index.php)作为fuzzing对象，这是一个php写的开源的HTML过滤器，有兴趣的话可以先到[http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php](http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php)这个网站，先手工测试一下看看能不能手工绕过它对CSS的过滤，也许大牛是可以手工XSS的，反正我试了一会没有成功，没办法，智商就只有这么多。这里我说的是上面那种例子里的样式表XSS，你可别直接输入一个