TSRC编辑：
Web2.0时代，XSS的脆弱性不容小觑。 特别是在UGC业务中，支持“安全的”HTML是业务所需的特性，因此对UGC安全过滤器的要求特别高，稍有不慎就会出现存储XSS漏洞。 腾讯安全中心从2007年开始面向内部UGC业务发布了“安全API”项目，解决了这样的场面。 原理是提前分析用户提交的内容，过滤出现安全问题的语句。 胖子在这方面经验丰富，我们来看看这是怎么实现的。 也欢迎demo的实测。 发现问题便于改善。
当然，整篇文章都是着眼于“方案”，有后续机会也可以讲API的运营故事(这个元老级项目故事很多)。 通过API的精细化运营，是能够发现0天漏洞的——API本身，也包括浏览器。 例如CVE-2009-1862、CVE-2011-2458、其他八卦。
存储型XSS漏洞，该漏洞行业的元老级漏洞类型，在当今的web2.0时代，一旦被利用，对业务的影响也会很大。 例如，以前的“XX咖啡广告”:
本文的主要目的是在支持富业务文本UGC的情况下，与大家一起讨论如何有效解决存储XSS漏洞。 如果有错误或者看漏的地方，请马上指出来。
说起XSS的漏洞，第一印象可能是只要将公开的XSS代码作为正规的代码全部屏蔽就万事大吉了，但很多人违背了愿望，付出了很大的努力，XSS的漏洞依然存在。 本文基于XSS漏洞生成原理，说明如何有效解决这一问题。
一：整体滤波流程图
别胡说，直接看过滤器的流程图：
2 :属性值过滤
这里很少提到正在过滤的标签和黑色属性。 我知道了删除就可以了。 特别是可以参考附件配置文件的标签和属性。 这里的重点是属性值是安全的
关于属性值，是正式进入本篇的关键，属性值大致分为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进行了评价。 黑名单上几乎没有使用方法
坑1 )黑名单清理完成后，您会发现IE浏览器居然与以下格式的CSS兼容() ) )。
坑2 )同时IE也兼容以下格式(代码、传统彩虹支持代码就算好，可以有也可以没有最后一个)
坑3 :你以为他只知道html代码吗？ 其实你错了。 他也知道unicode代码。
没办法，全部用黑名单做。 出现CSS，或者全部清空CSS。 清空CSS。
坑4 )这时，觉得CSS没问题，但传统的彩虹IE爷爷又出现了新的兼容方式(全角文字)
继续，出现全角文字后，全部清空。
IE啊IE，你这么牛逼，你家人都知道啊。
2.3闪存
就Flash安全性而言，重点保障allowscriptaccess:allow networking这两个属性值的设定是合理的就可以了
条件允许将allowScriptAccess统一设置为never，将allowNetworking统一设置为none
但是，业务中经常需要这两个属性，例如为了能够在QQ空间日志中播放QQ音乐，首先识别导入的Flash地址，只进行白名单的释放即可。
在此，强烈建议不要使用object。 因为他比embed处理麻烦n倍，IE爷爷的兼容性也非常高。 例如，识别属性名称时，还允许使用以下编码格式：
三.重写
结束兼职的最后一步，也是非常重要的一步。 重写这里之前遇到的漏洞是，用严格安全的用户封闭的文字做，被周围包围着死了。 之后，百了，根据HTML标准直接强制关闭双引号，所有属性值被编码并过滤。
注意： DOM分析识别style中的闭合字符为空格，并销毁无效的css后，该版本变为漏洞版本。
四.方案弊端
要在此计划中过滤的标记和属性必须预先知道，并且出现新标记时必须立即更新。 否则，就会出现XSS漏洞。 在这里经历了两次。 第一次是在html5中添加标签，第二次是
特性。 附件：过滤XSS使用代码的可执行程序和配置文件
使用方法如下。 (demo运行时环境为gcc4 linux32位系统) )。
./demo_filterall_aa输入文件1 1输出文件
输入用户的UGC: test.html
过滤结果：
德莫
欢迎大家测试，发现问题欢迎与我们交流security@tencent.com