2015年10月数据安全漏洞分析报告

报告核心观点

为了提高广大用户的安全意识，国内专业数据库安全厂商安华金和，综合来自补天、乌云、漏洞盒子等漏洞平台高危数据安全漏洞，发布每日安全资讯，数据库攻防实验室（DBSec Labs）以月为单位，将数百个高危漏洞汇总，形成分析报告，分享广大用户及合作伙伴。

10月报告核心观点

格局不变，SQL注入重回“王者”

白帽子“独爱”政府，60个漏洞

10月常见数据泄露原因分析

从SQL角度防守SQL注入

报告正文

2015年10月，安华每日安全资讯总结发布了154个数据泄密高危漏洞，这些漏洞分别来自乌云、补天、漏洞盒子等平台，涉及8个行业，公司机构、互联网、交通运输、教育、金融保险、能源、运营商、政府。同比9月份的134个，漏洞数量增加20个。10月份的漏洞中，SQL注入漏洞数量占总量的38%，重回“第一宝座”。

格局不改，SQL注入重回“王者”

数据安全问题多数是从Web端开始。10月份SQL注入漏洞再次引爆新高潮，被白帽子挖掘出58个SQL注入相关漏洞，这些漏洞遍及公司机构、互联网、政府等6个行业。SQL注入漏洞在10月份统计的漏洞总数中占据了近4成比例。

  
10月平台SQL注入漏洞占主要比重

10月的SQL注入漏洞与以往的SQL注入漏洞存在很大的不同点。以往SQL注入是由于平台缺乏对应的校验机制而导致注入成功。10月的SQL注入案例中很多平台的后台存在WAF，但入侵者绕过WAF进行SQL注入。这源于WAF的某些技术限制，确实存在一些手段可以绕过WAF进行SQL注入。

白帽子“独爱”政府，60个漏洞显现

从10月154个受到数据泄露漏洞威胁的行业来看，政府、互联网、行业机构依旧是重灾区。10月单月仅安华每日安全资讯统计出的154个高危漏洞中就有60个政府行业漏洞（包含了卫生医疗、教育、社保公积金几个子类）占比38%，互联网行业占全部数据泄露威胁的22%。行业机构紧随其后，漏洞比例占11%。

  
10月数据安全漏洞行业分布情况

 10月政府行业漏洞数量暴涨，本月政府行业有60个漏洞,同比9月份的43个增加了17个，占整体漏洞总数的38%。也是9月份以来三大高危行业（政府、互联网、行业机构）中，唯一漏洞数大幅攀升的行业。政府被集中爆出漏洞与自身网站的WAF策略配置有明显关系。政府漏洞中有24个漏洞是绕过WAF的SQL注入漏洞。60个中还存在两个弱口令漏洞、三个配置错误漏洞，弱口令直接被白帽子用工具爆破出密码。相信通过合理的制度和一定的辅助工具弱口令和配置错误应该能够被杜绝。在企业机构、教育、运营商和互联网中，也存在上述问题。虽然本月平台系统漏洞有明显减少，但依旧活跃在各个行业。错误配置、弱口令等人为因素依旧没有杜绝。

10月常见数据泄露原因分析

SQL注入是一种常见的黑客入侵WEB应用服务器的手法。SQL注入产生的根本原理在于SQL语言是一种解释型语言。解释型语言是一种在运行时由一个运行时组件解释语言代码并执行其中包含指令的语言。

SQL注入正是基于解释型语言的执行方式产生的。解释器处理的数据实际上是由程序员编写的代码和用户提交的数据共同组成的。黑客向Web应用发送精心构造的输入，这个输入中的一部分被解释成程序指令，改变原来的程序判断的逻辑。最终黑客可能通过SQL注入获取Web应用的管理员权限和Web应用存在数据库中的大量敏感信息。

10月份数据泄漏威胁主要原因

WAF虽然在一定程度上可以对SQL注入进行防护，但往往需要在性能和防护效果上做权衡。让WAF处于这种尴尬境地的原因在于SQL注入是从http和SQL两个角度进行入侵的手法，而WAF主要针对HTTP 协议进行解析。如果绕过的手法是出现在SQL语法中，WAF无法知道WEB应用中生成用于访问数据库完整的SQL语句，无法针对访问数据库的SQL语句进行分析、识别，于是只能考虑采用关键字过滤等方式来进行禁止，这种一个一个封堵的方式难以遍历所有SQL注入情况，在防守上存在遗漏，如果大量使用正则匹配又会降低性能。产生这些问题的根源都在于WAF无法对访问数据库的完整SQL语句做分析、识别。

由于WAF采用的是正则匹配的方式，于是出现了以下3中常见绕过WAF的手段：

（1）.编码绕过

在大小写绕过的基础上开始出现编码绕过，主要出现了三种：URL编码、十六进制编码、Unicode编码。在浏览器中输入URL会进行一次URL编码，黑客会通过多次编码来进行WAF绕过，例如：Id.php?id=1%2520union/**/select ，数据库得到的Id.php?id=1 union/**/select。如果只解码一次得到的是Id.php?id=1%20union/**/select，很有可能绕过WAF入侵数据库。针对这一问题可以采用多次循环解码来应对。其中Unicode编码种类很多，如果只是基于黑名单过滤，无法处理全部情况，其中UTF-32曾经实现过对GOOGLE的绕过。

（2）.注释绕过

不但可以采用编码改写关键字，还可以采用注释改写关键字，避免正则匹配。例如z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4 'union%a0select pass from users# 。就是用符号编码代替一部分字母和判定的空格来逃避正则匹配。（selectxxx不会被拦截，因为可能是函数名等。select 空格xxx则一定会被拦截，去掉空格成为绕过的关键）。同样还有针对MYSQL版本的/*!5000union*/系列。

（3）.等价替换

等价替换是个比较大的分类，主要可以分为等价函数、等价符号、特殊符号、比较符号等4类。

等价函数，就是同功能函数替换。WAF禁止了一些函数，但对另外一些函数没有禁止例如 Substring()可以用mid()，substr()这些函数来替换。还将可以采用生僻函数迂回完成原函数的功能，进行WAF关键字绕过。and or 这种关键字在PHP中可以用|| 和&&代替。于是语句id=1 or 1=1就可以写成id=1 || 1=来进行绕过。同样！= 、>、<等都可以代替等号进行绕过。

除去绕过关键字和关键符号外，最关键的是绕过空格。想各种方式避免空格出现。

例如 原句 id=1 or 1=1

可以写成  id=1+or+1=1

id=1%0bor%0b1=1

id=1--s%0aor--s%0a1=1

id=1/*!or*/1=1

id=1()or(1=1) 等多种形式进行尝试绕过

Waf解决上述问题的方法基本是在特征库中添加更多的过滤项。越多的过滤项，越慢的性能。

从SQL角度防守SQL注入

WAF擅长解析过滤http协议，不能对SQL语句进行整体分析。针对这个缺陷，可以在WEB应用和数据库之间加入数据库防火墙进行SQL部分的解析和过滤。数据库防火墙对从WEB应用发向数据库的SQL语句进行语法解析，可以理解SQL语句的真实含义，并做以下四点判断：

1、语句是否含有明显的SQL注入特征；

2、语句访问的对象是否属于该用户访问权限；

3、语句调用的核心函数是否存在高危漏洞；

4、限制语句的返回行数，把危险控制在最低限。

加入数据库防火墙后，数据库防火墙会在WEB应用和数据库之间获取WEB应用发送给数据库的SQL语句。通过拿到的SQL语句，按照不同数据库进行SQL协议解析。通过协议解析把应用发送的SQL语句还原成标准模式（去掉各种数据库兼容符号和特殊用法）防止黑客利用上述绕过WAF的手法绕过数据库防火墙进行SQL注入。首先还原后的SQL语句和黑名单中的禁止语句结构进行匹配，如果认为是威胁语句，则禁止该语句发送到数据库端，并通过发送短信、邮件等方式及时通知管理员进行处理；语句结构判断没有问题后防火墙接下来会对语句中的操作对象和谓词进行判断，如果对象或谓词有控制，则依旧禁止该语句发送到数据库端；即便绕过全部防护，SQL语句被发送到数据库端，数据库防火墙还可以通过限制返回行数来减小数据外泄的损失。

结束语

在防御SQL注入上WAF的最大问题是无法对WEB发给数据库的SQL语句进行获取、分析。只能通过正则匹配来尽量保证遍历每种情况，即使这样也无法保证完全遍历。如果为了达到完全遍历而设置大量的正则匹配，会对性能产生严重影响。因为技术路线原因导致WAF无法克服这种自身缺陷，而数据库防火墙则恰好弥补了WAF的技术路线缺陷。数据库防火墙的防护策略、手段都是基于SQL协议解析而来。数据库防火墙在防止SQL注入上彻底的解决了WAF以牺牲性能为代价的方式，相信如果数据库防火墙和WAF配合使用会使我们的数据库更加安全。

为了实现让数据使用更安全的使命，安华金和作为专业的数据库安全厂商，有义务和责任为客户提供创新前沿与稳定的数据库安全防护产品与解决方案。

最后，也是最重要的，用户还是要从主观因素上提高安全意识，加强内部安全管理防范。安全就是这样一种形态，平时不出状况看不到安全的效果，一旦企业出现了数据泄露事件，其经济损失、名誉损失将不可估量，更甚者会使企业形象一落千丈。

下载完整版：《2015年10月数据安全漏洞分析报告》