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

数据库审计产品常见缺陷（三）多语句无法有效分割继上期为大家介绍了有关数据库审计产品长SQL语句漏审的问题，本期，安华金和围绕多语句的有效分割分析数据库审计产品常见缺陷。多语句是SQL Server上的一个特定情况。在其它的数据库管理系统中，语句之间都有明确的分割标识；而在SQL Serve中语句之间可以没有明确的分隔符。下面是一个示例：use opencmsSET NOCOUNT ONselect * from opencms.opencms.CMS_LOGwhere 1=1 or ‘a’ =’b’select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1在这些语句之间没有类似于；号这样的明确分隔标识符；它们实际代表了四条语句：use opencmsSET NOCOUNT ONselect * from opencms.opencms.CMS_LOG where 1=1 or ‘a’ =’b’select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1SQL 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即使采用稍微复杂一些的技术，比如正则表达式，也很难做到准确切割；非专业化的数据库审计产品都存在这个缺陷。对无法准确切割多语句的缺陷，在不同的产品中表现不同，所造成的审计问题也不同，但大体可以总结为如下几点：在审计记录中，不能准确记录下每条语句的SQL操作类型，从而造成一些高危操作不能有效地被识别或告警，比如drop、truncate这些语句。在审计记录中，不能准确记录下每条SQL语句的数据库对象，从而造成对敏感对象的访问不能有效地被识别或告警。在审计记录中，不能准确地记录每条语句是否执行成功；比如多条语句中第一条语句执行成功，后面的语句执行失败了，往往会被整体记录为一个结果，往往记录的结果是成功。在审计记录中，不能准确地反馈出每条语句造成的影响行数，从而也无法触发基于影响行的安全策略；往往记录下来的都是第一条语句的影响行，其余语句的影响行都被忽略掉了。下面的结果是安华金和专业的数据库审计产品的执行结果，该产品准确实现了多语句切割，同时准确审计了每条语句的执行成功与否和影响行：以上结果，安华金和数据库审计系统根据语句发送的先后顺序进行了倒排显示，同时审计了每条语句的操作对象、SQL语句、执行成功与否，影响行数。安华金和的数据库审计专家准备了一些用例，来帮助读者验证数据库审计产品能否完成多语句切割，是否准确地审计了每条语句的访问对象、返回结果和影响行：用例一（一个很基本的多语句例子）INSERT INTO #AM_DBFILEIO(COLLECTION_TIME,TOTAL_IO_BYTES)VALUES(@CURRENT_COLLECTION_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 from #t1 t2 where not t2.object_id is null )用例二（一个稍显复杂点的，与游标相关的多语句示例）：DECLARE tables_cursor CURSORFORSELECT name FROM sysobjects WHERE type = UOPEN tables_cursorDECLARE @tablename sysnameFETCH NEXT FROM tables_cursor INTO @tablenameWHILE (@@FETCH_STATUS -1)BEGIN/* A @@FETCH_STATUS of -2 means that the row has been deleted.There is no need to test for this because this