安华金与：数据库审计产品常见缺陷之(三)多语句无法有效分割.pdf

数据库审计产品常见缺陷（三）多语句无法有效分割 继上期为大家介绍了有关数据库审计产品长 SQL 语句漏审的问题，本期， 安华金和围绕多语句的有效分割分析数据库审计产品常见缺陷。多语句是 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 即使采用稍微复杂一些的技术，比如正则表达式，也很难做到准确切割；非 专业化的数据库审计产品都存在这个缺陷。 对无法准确切割多语句的缺陷，在 不同的产品中表现不同，所造成的审计问题也不同，但大体可以总结为如下几点： © 2015 安华金和 （1）在审计记录中，不能准确记录下每条语句的SQL 操作类型，从而造成 一些高危操作不能有效地被识别或告警，比如drop、truncate 这些语句。 （2 ）在审计记录中，不能准确记录下每条SQL 语句的数据库对象，从而造 成对敏感对象的访问不能有效地被识别或告警。 （3 ）在审计记录中，不能准确地记录每条语句是否执行成功；比如多条语 句中第一条语句执行成功，后面的语句执行失败了，往往会被整体记录为一个结 果，往往记录的结果是成功。 （4 ）在审计记录中，不能准确地反馈出每条语句造成的影响行数，从而也 无法触发基于影响行的安全策略；往往记录下来的都是第一条语句的影响行，其 余语句的影响行都被忽略掉了。 下面的结果是安华金和专业的数据库审计产品的执行结果，该产品准确实现 了多语句切割，同时准确审计了每条语句的执行成功与否和影响行： 以上结果，根据语句发送的先后顺序进行了倒排显示，同时审计了每条语句 的操作对象、SQL 语句、执行成功与否，影响行数。 © 2015 安华金和 安华金和的数据库审计专家准备了一些用例，来帮助读者验证数据库审计产 品能否完成多语句切割，是否准确地审计了每条语句的访问对象、返回结果和影 响行： 用例一（一个很基本的多语句例子） INSERT INTO #AM_DBFILEIO(COLLECTION_TIME,TOTAL_IO_BYTES)VALUES(@CURRENT_COLLECTIO N_TIME,@CURRENT_TOTAL_IO_MB) insert #t1 ( object_id, object_type, rank) select t.relative_id, t.relative_type, 1 from #t1 t where t.relative_id not in ( select t2.object_id fr