【连载】数据库审计产品常见缺陷(4)数据库对象解析错误

继上期为大家介绍了有关数据库审计多语句无法有效分割的问题,本期,安华金和围绕数据库对象解析错误分析数据库审计产品常见缺陷。数据库审计产品中一个重要需求是要有效记录下来SQL语句的操作类型、访问对象;根据这些操作类型和访问对象,审计产品可以有效地制订告警策略,可以有效地根据操作类型、访问对象进行事后的追踪与检索。我国相关部门的数据库审计产品标准中要求:应对数据库网络访问对象的名称进行准确审计,包括数据库服务器名称、IP名称、数据库名称、表、视图、序列、包、存储过程、函数、库、索引和触发器等。

目前国内大多数数据库审计产品都会宣称支持对SQL语句操作类型和访问对象的审计支持;但事实上,很多审计产品的支持能力有限,往往只能支持一些简单语句的解析,比如这样的语句: 
Select * from tbl1 where col1 > ’1’;

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

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

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

出现这种情况说明产品设计的比较粗糙,还远远达不到专业的数据库审计产品的要求;这通常是一些网络审计产品厂商,未经过严肃的产品开发过程,仅对原有的网络审计产品进行了简单包装就推向了市场;这些厂商依靠已经积累的品牌和用户的信任,提供了不严肃的数据库审计产品。而国家相关部门在产品的认证过程中以及用户的演示中,并未真正仔细地对此进行测试。

事实上,上面被误报的例子,是一个非常简单的例子,大多数专业的数据库审计产品都不会犯这样的错误。事实上,真正的挑战要比上面的例子复杂很多。安华金和的数据库审计专家为读者准备了一些示例,读者可以验证下所使用的数据库审计产品是否支持对这些类型的语句的操作类型和访问对象的正确解析。下面的示例,若是未明确说明数据库类型,那么均可在Oracle上执行通过。

一、对带Schema的表能否准确解析并审计

示例1:

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

挑战:

是否准确识别出表名是tbl1,数据库名称是user1;

示例2:以下语句在SQL Server上可运行

SELECT [Name],

[SalesAmount]

FROM [AdventureWorks].[Production].[Product] P

挑战:

是否准确识别出表名是product,数据库名称是AdventureWorks,Schema名称是Production;

二、对Union中的多表能否准确解析并审计

如:

Select col1, col2 from tbl1

Union

Select col1,col2 from tbl2

Union

Select myCol1,myCol2 from tbl3

Union

Select col3,col4 from tbl1;

挑战:

是否准确识别出表是tbl1、tbl2、tbl3

三、对Update中的多表能否能否准确解析并审计

示例1:Oracle上的多表更新语句:

update landleveldata a set (a.gqdltks, a.bztks)= (select b.gqdltks, b.bztks from gdqlpj b where a.GEO_Code=b.lxqdm)

挑战:

是否准确识别出涉及的表包括landleveldata、gdqlpj

示例2:SQL Server上的多表更新语句:

update a set a.gqdltks=b.gqdltks,a.bztks=b.bztks from landleveldata a,gdqlpj b where a.GEO_Code=b.lxqdm

挑战:

是否准确识别出涉及的表包括landleveldata、gdqlpj

示例3:MySQL上的多表更新语句:

update landleveldata a, gdqlpj b set a.gqdltks= b.gqdltks, a.bztks= b.bztks where a.GEO_Code=b.lxqdm

挑战:

是否准确识别出涉及的表包括landleveldata、gdqlpj

四、对insert中的多表能否能否准确解析并审计

Insert语句有两种句式涉及多表:insert into .... Select....

Select ....into [table] from

示例1:

Insert into tbl1(col1,col2,col3) select col1,col2,col3 from tbl2 where tbl2.col1=’new’;
挑战:识别出tbl1和tbl2;

示例2:以下语句在SQL Server上可运行

Select col1,col2,col3 into tbl1 from tbl2 where tbl2.col1=’new’;

挑战:识别出tbl1和tbl2;

五、对join中的多表能否准确解析并审计:

Join是多表关联查询的基础,形式也更多样;挑战也更巨大:

示例1:简单join语句

Select t1.a,t2.b from t1, t2 where t1.c=t2.c

挑战:

将表t1和t2均识别出来

示例2:inner join的语句

Select t1.a,t2.b  from t1 inner join t2 ON t1.c=t2.c

left join t3 on t1.c=t3.c where t1.name like ‘刘%’ and prince = ‘北京’;

挑战:

将t1、t2、t3表都准确地识别出来。

示例3:一个更为复杂的join情况,该语句是在SQL Server中执行的,由开放应用软

opencms实际发出的,以下语句在SQL Server上可运行:

SELECT CLMNS.COLUMN_ID AS [ID],CLMNS.NAME AS [NAME],CLMNS.IS_NULLABLE AS [NULLABLE],
CAST(ISNULL(CIK.INDEX_COLUMN_ID,0)AS BIT)AS [INPRIMARYKEY],CLMNS.IS_IDENTITY AS [IDENTITY],USRT.NAME AS [DATATYPE],
ISNULL(BASET.NAME,N‘‘)AS [SYSTEMTYPE],CAST(CASE WHEN BASET.NAME IN(N‘nchar‘,N‘nvarchar‘)AND CLMNS.MAX_LENGTH<>-1 
THEN CLMNS.MAX_LENGTH/2 ELSE CLMNS.MAX_LENGTH END AS INT)AS [LENGTH],CAST(CLMNS.PRECISION AS INT)AS 
[NUMERICPRECISION],CAST(CLMNS.SCALE AS INT)AS [NUMERICSCALE],ISNULL(XSCCLMNS.NAME,N‘‘)AS [XMLSCHEMANAMESPACE],
ISNULL(S2CLMNS.NAME,N‘‘)AS [XMLSCHEMANAMESPACESCHEMA],
ISNULL((CASE CLMNS.IS_XML_DOCUMENT WHEN 1 THEN 2 ELSE 1 END),0)AS [XMLDOCUMENTCONSTRAINT],SCLMNS.NAME AS [DATATYPESCHEMA] 
FROM SYS.TABLES AS TBL 
INNER JOIN
SYS.ALL_COLUMNS AS CLMNS ON CLMNS.OBJECT_ID=TBL.OBJECT_ID LEFT 
OUTER JOIN 
SYS.INDEXES AS IK ON IK.OBJECT_ID=CLMNS.OBJECT_ID AND 1=IK.IS_PRIMARY_KEY LEFT 
OUTER JOIN 
SYS.INDEX_COLUMNS AS CIK ON CIK.INDEX_ID=IK.INDEX_ID AND CIK.COLUMN_ID=CLMNS.COLUMN_ID AND CIK.OBJECT_ID=CLMNS.OBJECT_ID AND 0=CIK.IS_INCLUDED_COLUMN 
LEFT OUTER JOIN 
SYS.TYPES AS USRT ON USRT.USER_TYPE_ID=CLMNS.USER_TYPE_ID 
LEFT OUTER JOIN 
SYS.TYPES AS BASET ON(BASET.USER_TYPE_ID=CLMNS.SYSTEM_TYPE_ID AND BASET.USER_TYPE_ID=BASET.SYSTEM_TYPE_ID)OR((BASET.SYSTEM_TYPE_ID=CLMNS.SYSTEM_TYPE_ID)
AND(BASET.USER_TYPE_ID=CLMNS.USER_TYPE_ID)AND(BASET.IS_USER_DEFINED=0)AND(BASET.IS_ASSEMBLY_TYPE=1))
LEFT OUTER JOIN 
SYS.XML_SCHEMA_COLLECTIONS AS XSCCLMNS ON XSCCLMNS.XML_COLLECTION_ID=CLMNS.XML_COLLECTION_ID 
LEFT OUTER JOIN 
SYS.SCHEMAS AS S2CLMNS ON S2CLMNS.SCHEMA_ID=XSCCLMNS.SCHEMA_ID 
LEFT OUTER JOIN 
SYS.SCHEMAS AS SCLMNS ON SCLMNS.SCHEMA_ID=USRT.SCHEMA_ID 
WHERE(TBL.NAME=‘CMS_HISTORY_PROJECTS‘ AND SCHEMA_NAME(TBL.SCHEMA_ID)=‘opencms‘)ORDER BY [ID] ASC

挑战:

将表名:[SYS].[ALL_COLUMNS];   [SYS].[INDEXES]; [SYS].[INDEX_COLUMNS];   [SYS].[SCHEMAS];   [SYS].[TABLES]; [SYS].[TYPES];   [SYS].[XML_SCHEMA_COLLECTIONS]都识别出来。

六、对子查询中的表能否准确记录并审计

子查询是另外一种复杂的情况,整个SQL语句中的表并未老老实实地呆在from语句和where语句之间,而是渗透到了语句中,这个时候我们要是审计到所有的表对象,将有更大的挑战。

示例1:一个简单的子查询语句

Select * from tbl1 where tbl1.col1 in (select col1 from tbl2 where col2=’中国’);

挑战:

识别出表tbl1和tbl2

示例2:在join中的子查询 
SELECT     P.ProductID, P.Name, P.ProductNumber, M.Name AS ProductModelName
FROM         Production.Product  P INNER JOIN
(SELECT     Name, ProductModelID
FROM          Production.ProductModel)  M 
ON P.ProductModelID = M.ProductModelID

挑战: 
识别出表Production.Product和Production.ProductModel

示例3:作为计算列的子查询,以下语句在SQL Server上可运行 
SELECT [Name],
(SELECT COUNT(*) FROM AdventureWorks.Sales.SalesOrderDetail S
WHERE S.ProductID=P.ProductID) AS SalesAmount
FROM [AdventureWorks].[Production].[Product] P

挑战:

识别出表AdventureWorks.Sales.SalesOrderDetail

[AdventureWorks].[Production].[Product]

七、一个充满挑战的示例,综合了各种因素

毫无疑问,下面这个示例将是所有基于正则表达等方式进行匹配分析的数据库审计产品的噩梦;这里融合了多种SQL复杂的语法特征,只有基于yacc/lex这样的词法和语法分析技术的专业数据库审计产品才能胜任;这条语句来源于OpenCMS开放应用,该语句在sqlserver中可执行: 
insert #t1 (object_id, object_type, relative_id, relative_type, rank)
select distinct
case when 77 = t.relative_type then obj2.parent_object_id else t.relative_id end, -- object_id
case when 77 = t.relative_type then 1 else relative_type end, -- object_type
dp.referenced_major_id, -- relative_id
case -- relative_type
when dp.class < 2 then
case when ‘U‘ = obj.type then 1
when ‘V‘ = obj.type then 2
when ‘TR‘ = obj.type then 3
when ‘AF‘ = obj.type then 4
when obj.type in ( ‘P‘, ‘RF‘, ‘PC‘ ) then 5
when obj.type in ( ‘TF‘, ‘FN‘, ‘IF‘, ‘FS‘, ‘FT‘ ) then 6
when exists (select * from sys.synonyms syn where syn.object_id = dp.referenced_major_id ) then 7
end
when dp.class = 2 then (case
when exists (select * from sys.assembly_types sat where sat.user_type_id = dp.referenced_major_id) then 8
else 9
end)
end,
3
from #t1 as t
join sys.sql_dependencies as dp on
-- reference table, view procedure
( class < 2 and dp.object_id = t.relative_id and t.relative_type in ( 1, 2, 3, 4, 5, 6, 77) )
--reference type
or ( 2 = class and dp.object_id = t.relative_id ) -- t.relative_type?
--reference xml namespace ( not supported by server right now )
--or ( 3 = class and dp.referenced_major_id = t.relative_id and 10 = t.relative_type )
left join sys.objects as obj on obj.object_id = dp.referenced_major_id and dp.class < 2 and obj.type in ( ‘U‘, ‘V‘, ‘P‘, ‘RF‘, ‘PC‘, ‘TF‘, ‘FN‘, ‘IF‘, ‘FS‘, ‘FT‘, ‘TR‘, ‘AF‘)
left join sys.objects as obj2 on obj2.object_id = t.relative_id and 77 = t.relative_type
where 3 = t.rank

挑战:

能够完全识别出访问的数据库表包括:#t1、sys.synonyms

sys.assembly_typessys.sql_dependencies、sys.objects

时间: 2024-08-28 14:12:51

【连载】数据库审计产品常见缺陷(4)数据库对象解析错误的相关文章

【连载】数据库审计产品常见缺陷(3)多语句无法有效分割

继上期为大家介绍了有关数据库审计产品长SQL语句漏审的问题,本期,安华金和围绕多语句的有效分割分析数据库审计产品常见缺陷.多语句是SQL Server上的一个特定情况.在其它的数据库管理系统中,语句之间都有明确的分割标识:而在SQL Serve中语句之间可以没有明确的分隔符.下面是一个示例: use opencms SET NOCOUNT ON select * fromopencms.opencms.CMS_LOG where 1=1 or 'a' ='b' select * fromopen

【连载】数据库审计产品常见缺陷(五)参数审计错误

参数绑定是数据库编程中常用的一种方法,通过这种方法,数据库系统可以减少编译次数,快速执行,提升效率:但这种编程方法将对数据库的审计带来挑战,在笔者所见到的若干数据库审计产品中,在这种情况下都出了不少的错误.有的是漏审了语句,有的是记录下了操作的语句,但将具体执行时所使用的参数记错了或漏记了.这些缺陷对于审计产品无疑很是致命. 为了详解这种情况,我们来看一下参数绑定的基本概念.我们在常规的图形化或命令行工具中,往往都是直接写上SQL语句,比如: Select * from person_info

【连载】数据库审计产品常见缺陷(1)-综述

随着信息化的发展,数据库安全问题成为当前政府和企业用户关注的焦点,数据库审计产品成为当前信息安全产品的新宠. 当前在市面上存在着几十种数据库审计产品,这些产品的来源大约有四种类型: 国内原先具有网络审计产品的厂商,在网络审计产品的基础上经过简单包装,推出的数据库审计产品,比如我国几大安全厂商推出的数据库审计产品: 国内厂商专门针对数据库通讯协议的特点,开发出专门的数据库审计产品,比如安华金和.思福迪.安恒.国都兴业和帕拉迪等: 国外的数据库审计产品,比如Imperva.Guardium等: OE

动态基线技术——技术开创数据库审计新纪元

近年来,随着相关法律法规的完善.国家等级化保护要求,以及行业风险管理和内控指标的出台,安全审计产品慢慢的为大家所熟悉.而近年来数据盗窃和数据泄露等高危事件频发,数据安全也越来越受各大企业和单位的重视.数据库审计就是一款保护用户数据安全的产品. 数据库审计现状与局限 数据库审计相关产品已经问世很长时间了,各大厂商的审计系统的工作原理都基本相似,如旁路数据采集.审计规则.报警等,下图展示为基本工作流程: 其中审计规则功能一直在传统数据库审计系统中占据重要位置,通过配置不同的审计规则,能够识别数据库中

虚拟化及云环境下数据库审计技术探讨(下)

在上篇文章也介绍到大部分的虚拟化及云环境下的数据审计技术探讨 接下来我们来进入更深的层次研究 场景三:应用和数据库分别托管部署在完全独立的第三方云计算平台 场景四是场景三的一种延伸与扩大,场景四主要指目前主流的第三方云平台提供商如阿里云.亚马逊.腾讯云.华为云.百度云等等,底层的硬件.存储.网络等等都对用户不透明,上层的虚拟机具体在哪个物理硬件服务器上,连接哪个物理交换机,用户一概不知道,如下图所示: 因此要用传统方式配置镜像,基本上没有可能,云平台提供商并不会提供底层资源的控制权给云主机租户,

选择数据库审计的三大理由

黑格尔曾说,"存在即合理",用在数据安全领域,同样适用.一款数据库安全产品的诞生,必有其存在的合理之处.有数据显示,超过90%的数据都是从数据库中泄露出去的,因此,围绕核心数据安全防护,数据库安全产品首当其中.从国内权威IT研究咨询机构CCW Research发布的2015年<数据库安全市场现状与发展趋势研究报告>报告中不难看到,数据库审计市场份额占据半壁江山,用户对数据库审计产品的认知度也比较高.那么,基于用户的需求,为什么要用这款产品呢,本文提出选择数据库审计产品的三个

云平台数据库安全系列之(二)数据库审计

虚拟化平台和传统网络环境共存,应用服务器和数据库服务器要在混合云平台进行数据库审计,就要区别于传统的部署方式,本文以vSphere虚拟平台为例,对数据库审计在混合虚拟化平台上的部署进行实践探讨. 一.传统数据库审计产品在虚拟化平台下的局限性 虚拟化能够应对 IT 部门面临的最紧迫难题:基础架构无序扩张,迫使 IT 部门将其 70% 的预算用于维护,而只留下很少的资源用于业务发展创新. 这一困难源于当今 x86 服务器的体系结构:它们的设计使其在同一时间只能运行一个操作系统和应用.这样一来,即使是

云端数据库审计系统

中安威士云数据库安全审计系统是中安威士(北京)科技有限公司自主研发的一款针对云数据库的安全管理工具.为用户提供在云环境下对数据库的安全审计,以实现对云数据库所面临的风险进行评估,对云数据库的操作内容进行全面审计等.产品由相互关联,且保护能力依次递增的系列功能模块构成.核心功能模块包括:敏感数据发现.性能审计.风险评估.数据库审计等.为客户带来的价值: 将云上数据访问活动可视化,提高数据安全管理能力: 满足合规要求,快速通过云等保等各种评测: 完善纵深防御体系,提升整体安全防护能力: 减少核心数据

使用sybase数据库审计系统有什么独特的产品特点

伴随网络技术的不断发展,现在已经开始有越来越多的工作都需要通过网络的方式来完成的.就是在这样的基础下,网络数据库的发展速度更是在不断增加中.在现实的生活中大家可以接触到的网络数据模型库也是非常多,但是现在最容易受到使用者喜欢的产品还是sybase数据库审计系统.虽然它开发和使用的年限都不是非常久,但是使用者的数量却是在不断的增加中,而且使用者的增加速度更是逐渐在上升当中. 其实最根本的原因还是跟sybase数据库审计系统本身所带有的产品特点离不开的.和其他的数据库非常不同的一点,便是sybase