数据库安全审计常见8种缺数据库安全审计常见8种缺陷.doc

 ? 2016 数据库安全审计常见8种缺陷 作者 安华金和 刘晓韬 随着信息化的发展，数据库安全问题成为当前政府和企事业单位用户关注的焦点，数据库审计产品已经成为当前信息安全产品的盛宠。 当前在市面上存在着几十种数据库审计产品，这些产品集中起来大约可分四种类型： 在网络审计产品的基础上经过简单包装推出数据库审计产品的既有网络审计产品厂商，比如国内几大安全厂商推出的数据库审计产品，安全圈都知道，不再例举； 针对数据库通讯协议的特点开发出专门的数据库审计产品的国内细分领域安全厂商，比如安华金和、思福迪、国都兴业、帕拉迪等； 国外的数据库审计产品，比如Imperva、Guardium等； OEM第三方的数据库审计产品，OEM对象可能来自国内，也可能来自国外，比如Imperva或韩国的DBInsight。 随着国产化采购政策的推动，处于安全性的考虑，国外数据库审计产???，不在本文的评论范围内。笔者将重点对国内数据库审计产品常见缺陷进行分析。以下分门别类，针对最常见的8类数据库安全审计产品缺陷展开讲解。 长SQL语句漏审 大多数的SQL语句都在1K以里长度，市面上的数据库审计产品大多都能准确记录下，也能实现正常的解析；但在SQL语句超过1.5K时，很多的数据库审计产品就会发生漏审，或者只能审计下部分SQL语句。 一般Oracle一个通讯包的长度在2K，单一包内能够容纳的语句长度大约在1.4K多一点（大约为1460）；超过这个大小的SQL语句一般会拆分成多包；在Oracle 11g下通常通讯包为2K，最大可以达到8K；对于Oracle数据库没有明确说明可兼容的SQL语句的长度，有的说32K或64K是个临界点，但笔者也曾作过尝试2M做的SQL语句也能发送并被Oracle正常解析。 对于一些数据库审计产品，由于没有将多个SQL通讯包进行有效解析和关联，在发生长SQL语句时会发生无法解析或解析不全的情况；具体表现是，对于长SQL语句并未记录，或仅记录了前半部分。 这种情况的危害是，对于有些业务系统中自身就包含长SQL语句，比如经分系统，报表系统，这些SQL语句会被漏记；同时，一些黑客或攻击人员会利用这样的一些漏洞，进行数据库攻击而不留下痕迹。比如，若某个数据库审计产品，是基于单包解析机制进行的，则对于超过1.5K的SQL语句无法记录或仅记录了前1.5K，则攻击者可以首先加入1.5K长的注释，然后再写语句，这样会发生漏审或被审计下来的信息无效。 多语句无法有效分割 多语句是SQL Server上的一个特定情况。在其它的数据库管理系统中，语句之间都有明确的分割标识；而在SQL Serve中语句之间可以没有明确的分隔符。下面是一个示例： use opencms SET NOCOUNT ON select * from opencms.opencms.CMS_LOG where 1=1 or ‘a’ =’b’ select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1 在这些语句之间没有类似于 ；号这样的明确分隔标识符；它们实际代表了四条语句： use opencms SET NOCOUNT ON select * from opencms.opencms.CMS_LOG where 1=1 or ‘a’ =’b’ select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1 SQL Server会将这些语句不加分割地组织在一个数据库通讯包中发送；对于一些专业化程度不高的数据库审计产品，会将这些语句作为一条语句审计下来。有效地实现多语句分割，需要非常专业的SQL解析技术。一些简单的方法，比如用select、use 、set这样的关键字来进行语句分割，稍微复杂的情况就不好处理了；下面这个示例，就无法用这种简单的方法处理： Select * from t1 where t1.col1 = 1 union select * from t2 where t2.col1 = 1 select * from t2 where t2.col1 = 1 即使采用稍微复杂一些的技术，比如正则表达式，也很难做到准确切割；非专业化的数据库审计产品都存在这个缺陷。 对无法准确切割多语句的缺陷，在不同的产品中表现不同，所造成的审计问题也不同，但大体可以总结为如下几点： （1）在审计记录中，不能准确记录下每条语句的SQL操作类型，从而造成一些高危操作不能有效地被识别或告警，比如drop、truncate这些语句。 （2）在审计记录中，不能准确记录下每条SQL语句的数据库对象，从而造成对敏感对象的访问不能有效地被识别或告警。 （3）在审计记录中，不能准