存储型XSS漏洞解决方案--在支持业务富文本UGC的前提下,如何有效解决存储XSS漏洞

时 代,XSS漏洞不容小觑。特别是在UGC业务,支持“安全的”HTML是业务必须的特性,这就对UGC安全过滤器要求特别高,稍有不慎就会出现存储XSS 漏洞。腾讯安全中心从2007年就面向内部UGC业务推出“安全API”项目用于解决这类场景,原理是对用户提交内容进行预解析,过滤掉产生安全问题的语 句

整篇文章着眼点在“方案”,后续有机会还可以说说API的运营故事。通过对API的精细化运营是可以发现0day漏洞的——API自身的,甚至包括浏览器。比如CVE-2009-1862CVE-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,极少出现黑名单里的用法,可以直接清空css。

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

       坑2:同时IE还兼容如下格式(&#编码)

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

       没办法,统统黑名单搞之:出现\ 或 &# 统统清空CSS

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

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

      2.3 Flash

讲到Flash安全,就重点保障2个属性值设置合理就行了:      
  allowScriptAccess
: & allowNetworking

如果条件允许建议统一设置为:allowScriptAccess设置为neverallowNetworking设置为none

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

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

三:重写

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

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

四:方案的弊端

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

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

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

输入为用户的UGC:test.html

过滤后结果为: