问题来源是,SQL数据库的 *** 作是通过SQL语句来执行的,而无论是执行代码还是数据项都必须写在SQL语句中,也就导致如果我们在数据项中加入了某些SQL语句关键字,比如SELECT、DROP等,这些关键字就很有可能在数据库写入或读取数据时得到执行。
解决方案
方案一:
采用预编译技术
使用预编译的SQL语句,SQL语句的语义不会是不会发生改变的。预编译语句在创建的时候就已经将指定的SQL语句发送给了DBMS,完成了解析,检查,编译等工作,所以攻击者无法改变SQL语句的结构,只是把值赋给?,然后将?这个变量传给SQL语句。当然还有一些通过预编译绕过某些安全防护的 *** 作,大家感兴趣可以去搜索一下。
方案二:
严格控制数据类型
在java、c等强类型语言中一般是不存在数字型注入的,因为在接受到用户输入id时,代码一般会做一个int id 的数据类型转换,假如我们输入的是字符串的话,那么这种情况下,程序就会报错。但是在PHP、ASP这些没有强调处理数据类型的语言,一般我们看到的接收id的代码都是如下等代码。
方案三:
对特殊的字符进行转义
数字型注入可以通过检查数据类型防止,但是字符型不可以,那么怎么办呢,最好的办法就是对特殊的字符进行转义了。比如在MySQL中我们可以对" '
"进行转义,这样就防止了一些恶意攻击者来闭合语句。当然我们也可以通过一些安全函数来转义特殊字符。如addslashes()等,但是这些函数并非一劳永逸,攻击者还可以通过一些特殊的方式绕过。
SQL注入:利用现有应用程序,将(恶意)的SQL命令注入到后台数据库引擎执行的能力,这是SQL注入的标准释义。随着B/S模式被广泛的应用,用这种模式编写应用程序的程序员也越来越多,但由于开发人员的水平和经验参差不齐,相当一部分的开发人员在编写代码的时候,没有对用户的输入数据或者是页面中所携带的信息(如Cookie)进行必要的合法性判断,导致了攻击者可以提交一段数据库查询代码,根据程序返回的结果,获得一些他想得到的数据。
SQL注入利用的是正常的HTTP服务端口,表面上看来和正常的web访问没有区别,隐蔽性极强,不易被发现。
SQL注入攻击过程分为五个步骤:
第一步:判断Web环境是否可以SQL注入。如果URL仅是对网页的访问,不存在SQL注入问题,如:http://www.../162414739931.shtml就是普通的网页访问。只有对数据库进行动态查询的业务才可能存在SQL注入,如:http://www...../webhp?id=39,其中?id=39表示数据库查询变量,这种语句会在数据库中执行,因此可能会给数据库带来威胁。
第二步:寻找SQL注入点。完成上一步的片断后,就要寻找可利用的注入漏洞,通过输入一些特殊语句,可以根据浏览器返回信息,判断数据库类型,从而构建数据库查询语句找到注入点。
第三步:猜解用户名和密码。数据库中存放的表名、字段名都是有规律可言的。通过构建特殊数据库语句在数据库中依次查找表名、字段名、用户名和密码的长度,以及内容。这个猜测过程可以通过网上大量注入工具快速实现,并借助破解网站轻易破译用户密码。
第四步:寻找WEB管理后台入口。通常WEB后台管理的界面不面向普通用户
开放,要寻找到后台的登陆路径,可以利用扫描工具快速搜索到可能的登陆地址,依次进行尝试,就可以试出管理台的入口地址。
第五步:入侵和破坏。成功登陆后台管理后,接下来就可以任意进行破坏行为,如篡改网页、上传木马、修改、泄漏用户信息等,并进一步入侵数据库服务器。
SQL注入攻击的特点:
变种极多,有经验的攻击者会手动调整攻击参数,致使攻击数据的变种是不可枚举的,这导致传统的特征匹配检测方法仅能识别相当少的攻击,难以防范。
攻击过程简单,目前互联网上流行众多的SQL注入攻击工具,攻击者借助这些工具可很快对目标WEB系统实施攻击和破坏。
危害大,由于WEB编程语言自身的缺陷以及具有安全编程能力的开发人员少之又少,大多数WEB业务系统均具有被SQL注入攻击的可能。而攻击者一旦攻击成功,可以对控制整个WEB业务系统,对数据做任意的修改,破坏力达到及至。
SQL注入的危害和现状
SQL注入的主要危害包括:
未经授权状况下 *** 作数据库中的数据
恶意篡改网页内容
私自添加系统帐号或者是数据库使用者帐号
网页挂木马
如何防止SQL参数:
1,检查上传的数据,并过滤
2. 禁止拼接SQL字符串
3.使用SQL参数化处理
4.加载防入侵等硬件设施
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)