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

随着信息化的发展，数据库安全问题成为当前政府和企事业单位用户关注的焦点，数据库审计产品已经成为当前信息安全产品的盛宠。

当前在市面上存在着几十种数据库审计产品，这些产品集中起来大约可分四种类型：

（1）在网络审计产品的基础上经过简单包装推出数据库审计产品的既有网络审计产品厂商，比如国内几大安全厂商推出的数据库审计产品，安全圈都知道，不再例举；

（2）针对数据库通讯协议的特点开发出专门的数据库审计产品的国内细分领域安全厂商，比如安华金和、思福迪、国都兴业、帕拉迪等；

（3）国外的数据库审计产品，比如Imperva、Guardium等；

（4）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）在审计记录中，不能准确地记录每条语句是否执行成功；比如多条语句中第一条语句执行成功，后面的语句执行失败了，往往会被整体记录为一个结果，往往记录的结果是成功。

（4）在审计记录中，不能准确地反馈出每条语句造成的影响行数，从而也无法触发基于影响行的安全策略；往往记录下来的都是第一条语句的影响行，其余语句的影响行都被忽略掉了。

数据库对象解析错误

数据库审计产品中一个重要需求是要有效记录下来SQL语句的操作类型、访问对象；根据这些操作类型和访问对象，审计产品可以有效地制订告警策略，可以有效地根据操作类型、访问对象进行事后的追踪与检索。我国相关部门的数据库审计产品标准中要求：应对数据库网络访问对象的名称进行准确审计，包括数据库服务器名称、IP名称、数据库名称、表、视图、序列、包、存储过程、函数、库、索引和触发器等。

目前国内大多数数据库审计产品都会宣称支持对SQL语句操作类型和访问对象的审计支持；但事实上，很多审计产品的支持能力有限，往往只能支持一些简单语句的解析，比如这样的语句：

Select * from tbl1 where col1 > ’1’;

但笔者曾经见过一家大型的信息安全厂商的产品，仅仅是在表名前增加一个schema名称，就发生了令人震惊的错误；这个产品居然将schema名称审计为了表名。如上面这条语句改为；

Select * from user1.tbl1 where col1 > ‘1’;

这种数据库审计产品就会将user1记录为表名。

事实上，上面被误报的例子，是一个非常简单的例子，大多数专业的数据库审计产品都不会犯这样的错误。事实上，真正的挑战要比上面的例子复杂很多。

参数审计错误

参数绑定是数据库编程中常用的一种方法，通过这种方法，数据库系统可以减少编译次数，快速执行，提升效率；但这种编程方法将对数据库的审计带来挑战，在笔者所见到的若干数据库审计产品中，在这种情况下都出了不少的错误。有的是漏审了语句，有的是记录下了操作的语句，但将具体执行时所使用的参数记错了或漏记了。这些缺陷对于审计产品无疑很是致命。

为了详解这种情况，我们来看一下参数绑定的基本概念。我们在常规的图形化或命令行工具中，往往都是直接写上SQL语句，比如：

Select * from person_info where id=’12XXXXX6722’;

在这里查询条件是身份证号码。根据身份证号码查询个人信息，是一种常用功能，也是会重复使用的语句，为了提升效率，编程中可以这么写：

String sql1=’Select * from person_info where id=?;’

PreparedStatement pStmt = testConn.getConnection().prepareStatement(sql);

pStmt.setInt(1, ’12XXXXX6722’);

pStmt.execute();

下一次再使用时，就不用再发送语句了，可以直接发送：

pStmt.setInt(1, ’22XXXXX5399’);

pStmt.execute();

对于数据库审计系统而言，单纯地记录下来‘Select * from person_info where id=?’是存在缺陷的，因为你无法明确额操作人员到底访问了哪个用户的信息，必须明确下来具体的参数才行。

这就要求将设定的参数，与Prepare的语句有效的关联，形成可视化的审计记录展现:

Select * from person_info where id=’12XXXXX6722’;

Select * from person_info where id=’22XXXXX5399’;

这实际上要求审计系统比起单纯的记录语句要完成更多的工作；其中一个重要任务的就是句柄追踪，本质上SQL语句的执行过程追踪就是句柄追踪过程。在上面显示的例子中，pStmt.execute()，在通讯过程中并不发送具体的语句，而仅是告知服务器要执行哪个语句句柄，服务器端会根据内部记录的句柄所对应的已经编译完成的SQL语句的执行计划，进行语句执行。数据库审计要完成相应的工作，需要执行类似的过程，在系统的内部也维护这样的映射关系；同时由于大多数数据库的句柄，是在会话级的，句柄是可重用的，因此在数据库审计中还要有效地维护句柄与session的关联，以及句柄的消亡。

在句柄维护之外，另一个有挑战的工作就是参数的还原。参数的还原，首要的是要明确参数所对应的句柄；在调用pStmt.setInt(1, ’22XXXXX5399’)时，在网络中发送的包，会标明这个参数是针对哪个句柄的，是针对第几个参数的。作为数据库审计产品，需要将参数与语句进行映射；更重要地要准确地填回参数所在的位置，上面这个例子由于只有一个参数，没有什么挑战性，参数的绑定情况远比这个复杂。

除了以上列举的4个常见缺陷，在实际情况下还有一些常见的缺陷：

错误的应答结果，特别是影响行数解析不正确

对于SQL操作是否成功，是数据库审计的基本需求；对数据库操作读取或影响了多少行是用户的实际需求。但SQL操作成功与否的准确记录，需要仰仗SQL语句的合理切割和句柄的准确追踪及对返回结果集的完全解析；大多数数据库审计产品在多语句情况，或者通过FETCH操作批量获取等环节下，无法准确获得查询执行的正确性以及影响行数。

充满失真率的应用用户关联

市场上的数据库审计产品大多数都宣传支持三层关联审计，实现SQL语句与业务用户的关联。这种基于三层关联审计的技术，是通过http协议中的参数与SQL语句中的参数的匹配，以及时间的匹配来完成的，属于模糊匹配。这种方法在http参数经过加工后或基于逻辑判断后再发出SQL语句，也即SQL语句的参数与http参数没有直接的匹配关系时将完全失效；在高并发时更是一个灾难。这种方法的准确率往往很难超过80%。

不够专业化的审计界面

这个问题主要是针对基于网络审计而发展来的数据库审计产品，这种产品由于在设计之初就不是专门面向数据库用户的，因此并未按照数据库的访问类别、会话追踪、数据库对象层次进行界面组织，造成这类产品的界面极其不易使用。

过度冗余的审计信息存储

很多应用系统会采用动态拼接SQL语句的方式来实现对数据库的访问；这会造成大量SQL语句语法形式相同而仅仅是SQL语句中的参数值不同的语句。当前的很多审计产品将这些语句进行重复地记录和存储，造成了审计效率的低下，存储设备的浪费，并会对SQL语句的分析和排查效率造成致命影响。

作为国内专业的数据库安全厂商，安华金和数据库审计产品（DBAudit）可以有效避免以上8类缺陷常见缺陷。

——作者：安华金和 刘晓韬