解析检查--存储型XSS漏洞解决方案

Web2.0时代，XSS漏洞不容小觑。特别是在UGC业务，支持“安全的”HTML是业务必须的特性，这就对UGC安全过滤器要求特别高，稍有不慎就会出现存储XSS漏洞。

整篇文章着眼点在“方案”，后续有机会我们还可以说说API的运营故事(这个元老级项目故事很多)。通过对API的精细化运营是可以发现0day漏洞的——API自身的，甚至包括浏览器。比如CVE-2009-1862、CVE-2011-2458 以及一些其他八卦。

存储型XSS漏洞，这个作为漏洞界的元老级漏洞类型，在当前web2.0时代，一旦被利用，对业务造成的影响也将是轰轰烈烈的，比如之前的“XX咖啡广告”：

本文的主要目的是和大家一起探讨在支持业务富文本UGC的前提下，如何有效解决存储XSS漏洞，如果有写的不对或遗漏的地方，欢迎大家及时指正。

提到XSS漏洞，很多人可能第一印象就是把已公开的xsscode弄个正则全部屏蔽就万事大吉，但是往往事与愿违，付出了巨大的努力，XSS漏洞还依然存在。本文就根据XSS漏洞生成原理来逐个讲讲如何有效解决该问题。

一：整体过滤流程图

废话少说，直接看过滤流程图：

二：属性值过滤

针对过滤流程中的标签及黑属性，这里就不多说了，发现删除就可以，具体是哪些标签及属性可参考附件的配置文件，这里重点说下属性值安全

谈到属性值，才算正式进入本篇的重点，属性值大体分为3类

2.1 URL

这里指的URL，就是类似href，src等的值，这里核心的就是按照URL标准识别出引入的URL的协议，保留允许的协议即可，比如

2.2 CSS

为什么要提到CSS呢，因为CSS是富文本UGC的一个核心，因为没有CSS，QQ空间日志内容则达不到用户想要的炫酷效果，为了保证CSS的安全，我们又得再实现一个CSS语法解析器(由于当时场景需要，我们是自己写的，不过大家也可以参考CSS Parse的开源代码)。

由于CSS的强大，所以我们首先定义了一串黑名单，比如出现expression，background，javascript，eval一旦出现这些黑名单，这里之前犯过一个错误，就是采用删除逻辑，当遇到下面的case，真的是欲哭无泪，后来评估正常UGC，极少出现黑名单里的用法，so直接清空css。

坑1：在完成黑名单清理后，你会发现IE浏览器竟然兼容如下格式的CSS(强大的)

坑2：同时IE还兼容如下格式(&#编码，尼玛的支持编码就算了，最后的;还可有可无)

坑3：你以为他只认识html编码嘛，其实你错了，他还认识unicode编码。

没办法，统统黑名单搞之：出现 或 &# 统统清空CSS啊，清空CSS。

坑4：此时，你以为CSS应该没事了，但是IE又出现新的兼容方式：全角字符

继续搞，只要出现全角字符，一概清空。

2.3 Flash

讲到Flash安全，就重点保障2个属性值设置合理就行了：

allowScriptAccess： & allowNetworking

如果条件允许建议统一设置为：allowScriptAccess设置为never，allowNetworking设置为none

但是业务往往需要这2个属性，比如QQ空间日志中要能播放QQ音乐，所以需要首先识别出引入的Flash地址，然后仅对白名单的放开该权限即可。

这里强烈建议大家不要使用object，因为他比embed处理要麻烦N倍，同时IE大爷对它兼容也超好，比如当识别属性名时，如下编码格式也是允许的：

三：重写

打完收工的最后一步，也是蛮重要的一步，重写这里之前遇到个坑，就是严格安全用户的闭合字符来做，导致被绕的死去活来，后来一了百了，按照HTML标准直接强制双引号闭合，属性值全部编码过滤。

注：DOM解析识别出style的闭合字符为空格，在丢弃无效的css后，结果变成了有漏洞的版本了。

四：方案的弊端

该方案要过滤的标签、属性都是要提前已知的，如果出现新标签，则要及时更新，不然会出现XSS漏洞，这里就经历过2次，第一次为html5新增标签、第二次则为LISTING特性。

附：过滤XSS利用代码的可执行程序及配置文件

使用方法如下：(demo运行环境为gcc4 & linux32位系统)

./demo_filterall_aa输入文件 1 1 输出文件

输入为用户的UGC：test.html