从安全攻击实例看数据库安全(三)数据库攻击原理分析

摘要:本文将通过对SQL注入攻击技术和数据库加密技术原理以及防护效果进行深入的分析,来辨析数据库安全技术误区“数据库加密能解决SQL注入”,同时本文也给出了SQL注入的防护方法。

1、 数据库安全误区

针对2015年4月互联网大规模报道的全国30省市社保等行业用户信息泄露事件,安华金和对乌云历史报道的社保行业相关漏洞进行集中分析,得出的结论为:大量的信息泄露主要是由于软件中存在的SQL注入漏洞被黑客利用引起的,我们可以把SQL注入比作黑客攻击数据库“锋利的矛”。
             有了攻击用的矛,我们再来看防守用的盾:数据库加密技术真正实现了敏感数据的加密存储,采用国内外主流的加密算法,确保加密后的数据通过非正常手段获取后十年内难以非法破解,同时通过独立权控、应用绑定,防止绕过合法应用程序的数据库访问和对内部高权限人员的运维操作管控,号称数据库安全中的王冠,我们可以把数据库加密技术比作数据安全防护措施中“坚固的盾”。
             《韩非子难一》所述的故事中提到:“以子之矛,陷子之盾,何如?”虽然这是个众人皆知的故事,但是现实版的“矛与盾”的故事又发生在大学教材《信息系统安全概论》中,下面我们先引用教材中的原文:

对于安全管理员来说,是否可以通过数据库加密来防止SQL注入呢?在详细解释两种攻防技术前,我们对一个误区给予纠正:数据库加密技术无法抵御SQL注入。原因是数据库加密解决信用卡信息存储安全等问题,而SQL注入是利用应用的弱点窃取数据,由于合法应用肯定能看到明文的信息卡数据,因此加密防守无效。

那SQL注入如何正确防护呢?下面我们先了解下SQL注入攻击的原理。

对于安全管理员来说这也是必要的,因为不仅要了解防护的手段,同时也应该深入了解SQL注入的原理,实现有针对性的安全防护。

2、 SQL注入攻击的原理分析

SQL注入数据库攻击指构建特殊的输入作为参数传入Web应用程序,比如通过提交表单的文本框输入,而这些输入大都是SQL语法里的一些组合,通过执行SQL语句进而执行攻击者所要的操作,其主要原因是程序没有细致地过滤用户输入的数据,致使非法数据侵入系统。

常见的SQL注入案例有两种情况,一种是伪装登录应用系统,另一种是在有登录账号的情况下,在应用系统后续的提交表单的文本框中找到SQL注入点,然后利用注入点批量窃取数据。如下两图的输入:

SQL注入的典型场景一,通过伪装登录窃取数据,主要是通过or运算符。

窃取数据

假设后台的拼接语句为select * from  table where column1=‘ 文本框输入值’ ;

Eg1:  如输入值为《abc ’  or  ‘1’=‘1》,  则语句拼接为 select  *…where column1=‘abc’  or ‘1’=‘1’;由于’1’=‘1’是恒真,则该可以看到了整表的全部数据。

骗取登录

一般系统的登录需要输入用户名、密码;后台拼接的语句为select  * from t where name=‘用户名’  and pwd=md5(‘密码’);

Eg1:  如输入用户名《abc ’  or  1=1 or 1=‘ def》,密码《abcd》则语句拼接为:

select  …where name=‘abc’  or  1=1 or 1=‘def’ and pwd = md5(‘abcd’);                由于1=1是恒真,则该语句永远为真,可以成功登录了。

SQL 注入典型场景二,探测(通过and 运算)。

探测系统变量

… and  user>0

我们知道,user是SQLServer的一个内置变量,它的值是当前连接的用户名,类型为nvarchar。拿一个 nvarchar的值跟int的数0比较,系统会先试图将nvarchar的值转成int型,当然,转的过程中肯定会出错,SQLServer的出错提示是:将nvarchar转换int异常,XXXX不能转换成int。

探测系统对象名

先猜表名

… and (Select count(*) from 表名)<>0

猜列名

… and (Select count(列名) from 表名)<>0

3、 数据库加密防护效果分析


面临风险


应对策略


数据库文件采用明文存储


以列为单位有选择的进行加密,将信用卡信息表中的姓名、身份证、信用卡等敏感信息加密存储。

面临风险


应对策略


数据库正常运维操作和敏感数据访问操作从权限上无法分开。


通过独立权控体系;通过三权分立的方式提升安全性;避免数据库维护人员直接接触明文数据


面临风险


应对策略


绕过应用服务器的访问。


通过客户端权限区分合法访问源,可对访问源的IP,访问时间进行鉴别,只有通过合法访问源才可以访问到数据。

面临风险


应对策略


绕过应用程序的访问。


通过应用绑定技术实现应用身份鉴别。
                   只有通过合法应用,才可以访问到被保护的敏感数据。

面临风险


应对策略


数据库备份明文存储。


对数据库文件底层直接加密,数据库备份文件导出后内容仍为密文,备份文件还原后仍为密文。

数据库加密防护总结:

4、 结论:SQL注入如何防护

卡尔的SQL注入攻击就是利用合法应用的弱点获取信息卡资料的,即使数据库信用卡信息加密了,从存储文件上看是密文,但是对于合法应用发过来的查询语句,数据库也必然解密后将明文数据发回web应用系统。

数据库安全专家安华金和建议通过WAF和数据库防火墙相结合来实现SQL注入的有效防护。WAF通过黑名单机制针对有SQL注入特征的表单内容进行拦截,数据库防火墙通过构建合法应用的行为模型和SQL注入特征库实现SQL注入行为的有效拦截,同时还能够对运维终端的恶意操作进行拦截。

时间: 2024-10-26 02:36:38

从安全攻击实例看数据库安全(三)数据库攻击原理分析的相关文章

【连载】从安全攻击实例看数据库安全(二)安全攻击方法分析

回顾: 在上一章中主人公卡尔采用多种攻击方法对好运公司的网络信息系统进行攻击,通过MAC地址欺骗取得了与公司内部网络的连接,通过口令破解,以远程方式登录公司内部服务器,通过缓冲区溢出漏洞闯进了操作系统并拥有最高权限,最关键的是卡尔以好运公司信用卡信息为目标,通过三种途径,包括web应用的文件上传漏洞.SQL注入攻击和绕过合法应用的方法,批量导出数据库中大量的敏感信息. 攻击的方法多种多样,这些方法有的在上面攻击的实例中用过,有的随攻击对象的情形而变化,但也是有规律可循的.总的来说,攻击是一步一步

从安全攻击实例看数据库安全

兵法曰:知彼知己,百战不殆.功与防的对抗是信息安全的主题,了解安全攻击才能更好地进行安全防御.本文对网络信息安全攻击的实例考察,通过了解黑客攻击的路径及技术手段,让读者初步建立信息安全攻击威胁的感性认识,让安全从业者更多站在攻击者的视角思考安全防护. 以上这个故事发生在一个发达国家,时间也并不久远,主人公卡尔是一个曾做过软件开发工程师,深谙信息安全攻击之术,他实施信息安全攻击的意图非常明显,就是要获取经济利益,而不只是通过恶作剧来达到炫耀自己的目的. 卡尔从报纸上看到好运公司发展迅猛,近一年时间

嵌入式linux QT开发(三)——GUI原理分析

嵌入式linux QT开发(三)--GUI原理分析 一.命令行程序 命令行程序是面向过程的程序设计. 命令行程序的特点: A.基于顺序结构执行 B.程序执行过程中不需与用户交互 C.程序执行结束给出最终运行结果 命令行程序适用场合: A.单任务场合 B.无交互.简单交互场合 C.服务器应用场合 二.GUI程序 GUI程序的特点: A.基于消息驱动模型的程序 B.程序执行依赖用户交互过程 C.程序执行过程中实时响应用户操作 D.一般程序执行后不会主动退出 GUI程序适用场合: A.多任务场合 B.

常见的数据库攻击方法

下面是六大数据库攻击: 1.强力(或非强力)破解弱口令或默认的用户名及口令 2.特权提升 3.利用未用的和不需要的数据库服务和和功能中的漏洞 4.针对未打补丁的数据库漏洞 5.SQL注入 6.窃取备份(未加密)的磁带 下面分别分析一下: 1.对弱口令或默认用户名/口令的破解 以前的Oracle数据库有一个默认的用户名:Scott及默认的口令:tiger;而微软的SQL Server的系统管理员账户的默认口令是也是众所周知. 当然这些默认的登录对于黑客来说尤其方便,借此他们可以轻松地进入数据库.

【转载】如果有人问你数据库的原理,叫他看这篇文章

原文:如果有人问你数据库的原理,叫他看这篇文章 本文由 伯乐在线 - Panblack 翻译,黄利民 校稿.未经许可,禁止转载!英文出处:Christophe Kalenzaga.欢迎加入翻译组. 一提到关系型数据库,我禁不住想:有些东西被忽视了.关系型数据库无处不在,而且种类繁多,从小巧实用的 SQLite 到强大的 Teradata .但很少有文章讲解数据库是如何工作的.你可以自己谷歌/百度一下『关系型数据库原理』,看看结果多么的稀少[译者注:百度为您找到相关结果约1,850,000个…] 

服务的扩展性(如何创建具有可扩展性的服务实例,缓存以及数据库)

转自:http://www.cnblogs.com/loveis715/p/5097475.html 在编写一个应用时,我们常常考虑的是该应用应该如何实现特定的业务逻辑.但是在逐渐发展出越来越多的用户后,这些应用常常会暴露出一系列问题,如不容易增大容量,容错性差等等.这常常会导致这些应用在市场的拓展过程中无法快速地响应用户的需求,并最终失去商业上的先机. 通常情况下,我们将应用所具有的用来避免这一系列问题的特征称为非功能性需求.相信您已经能够从字面意义上理解这个名词了:功能性需求用来提供对业务逻

levelDB数据库使用及实例 - 高性能nosql存储数据库

LevelDB是google公司开发出来的一款 超高性能kv存储引擎,以其惊人的读性能和更加惊人的写性能在轻量级nosql数据库中鹤立鸡群. 此开源项目目前是支持处理十亿级别规模Key-Value型数据持久性存储的C++ 程序库.在优秀的表现下对于内存的占用也非常小,他的大量数据都直接存储在磁盘上.可以理解为以空间换取时间. 任何东西都不是十全十美的,LevelDB也有它的局限性: LevelDB 只是一个 C/C++ 编程语言的库, 不包含网络服务封装, 所以无法像一般意义的存储服务器(如 M

[转]如果有人问你数据库的原理,叫他看这篇文章

推荐一篇文章:http://blog.jobbole.com/100349/  --原文出处 一提到关系型数据库,我禁不住想:有些东西被忽视了.关系型数据库无处不在,而且种类繁多,从小巧实用的 SQLite 到强大的 Teradata .但很少有文章讲解数据库是如何工作的.你可以自己谷歌/百度一下『关系型数据库原理』,看看结果多么的稀少[译者注:百度为您找到相关结果约1,850,000个…] ,而且找到的那些文章都很短.现在如果你查找最近时髦的技术(大数据.NoSQL或JavaScript),你

缓冲区溢出攻击(待看)

缓冲区溢出攻击 本词条缺少信息栏.名片图,补充相关内容使词条更完整,还能快速升级,赶紧来编辑吧! 缓冲区溢出攻击是利用缓冲区溢出漏洞所进行的攻击行动.缓冲区溢出是一种非常普遍.非常危险的漏洞,在各种操作系统.应用软件中广泛存在.利用缓冲区溢出攻击,可以导致程序运行失败.系统关机.重新启动等后果. 1简介编辑 缓冲区溢出是指当计算机向缓冲区内填充数据位数时超过了缓冲区本身的容量,溢出的数据覆盖在合法数据上.理想的情况是:程序会检查数据长度,而且并不允许输入超过缓冲区长度的字符.但是绝大多数程序都会