最新消息:

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

xss admin 886浏览 0评论

博文作者:大马胖子

发布日期:2014-06-24

阅读次数:675

博文内容:

 

TSRC编者按:


Web2.0
时 代,XSS漏洞不容小觑。特别是在UGC业务,支持“安全的”HTML是业务必须的特性,这就对UGC安全过滤器要求特别高,稍有不慎就会出现存储XSS 漏洞。腾讯安全中心从2007年就面向内部UGC业务推出“安全API”项目用于解决这类场景,原理是对用户提交内容进行预解析,过滤掉产生安全问题的语 句。大马胖子在这方面经验丰富,大家可以看看这块是如何实现的。也欢迎实测demo,发现问题方便我们改进。


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




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

 

jinglingshu_2014-07-27_18-39-58


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


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


一:整体过滤流程图


废话少说,直接看过滤流程图:

                            jinglingshu_2014-07-27_18-39-37


二:属性值过滤


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


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

2.1 URL


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

jinglingshu_2014-07-27_18-39-36

      2.2 CSS


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


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

jinglingshu_2014-07-27_18-39-44

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

jinglingshu_2014-07-27_18-39-361

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

jinglingshu_2014-07-27_18-40-19

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

jinglingshu_2014-07-27_18-39-461

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

 

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

jinglingshu_2014-07-27_18-39-52

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

       不得不感慨一句:IE啊IE,你这么牛逼,你家人知道嘛。。。

 

      2.3 Flash


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

allowScriptAccess
: & allowNetworking


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


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


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

jinglingshu_2014-07-27_18-39-46


三:重写


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

jinglingshu_2014-07-27_18-40-02

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

四:方案的弊端


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

 

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


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


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


输入为用户的UGC:test.html

jinglingshu_2014-07-27_18-40-15


过滤后结果为:

jinglingshu_2014-07-27_18-40-151


Demo
下载地址:见TSRC实验室

欢迎大家测试,发现问题欢迎与我们交流 security@tencent.com

转自:http://security.tencent.com/index.php/blog/msg/53

转载请注明:jinglingshu的博客 » 解析检查 —— 存储型XSS漏洞解决方案


Warning: Use of undefined constant PRC - assumed 'PRC' (this will throw an Error in a future version of PHP) in /usr/share/nginx/html/wp-content/themes/d8/comments.php on line 17
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址