SQL注入漏洞及绑定变量浅谈
1、一个问题引发的思考
大家在群里讨论了一个问题,奉文帅之命写篇作文,且看:
String sql = "update user set user_web="+user_web+" where userid=2343";
大家看看这条sql有没有问题,会将user_web字段 更新成什么?
问题的结论是:执行后的记录结果跟执行前一样,(执行时的sql语句为
user_web字段值被update为自己原有的值),这与作者的本意想违背却很难被发现有问题。原来的语句漏掉了一对单引号,正确的写法应该是:
用这种写法将变量值传递到sql语句中,意图是达到了,但不是好的方式,理由如下:
1.可读性差。单引号双引号混杂(试想有多个变量的情况,再想下如果稍一不慎在前面的单引号双引号直间多个空格又会怎样?)
2.会造成潜在的性能问题和sql注入漏洞(对测试代码而言,这两点可能要求不高,但养成良好的编码习惯还是很重要的)
下面以非专业人员的角度大致分析下 ‘”+变量+”‘(未采用绑定变量方式)这种方式组织sql为什么会造成潜在的性能问题和sql注入漏洞问题
2、性能问题
Sql代码不采用绑定变量的方式可能会造成性能问题,表现在以下两个方面:
1.导致相同的测试计划被重复执行
sql语句的执行过程分几个步骤:语法检查、分析、执行、返回结果。当一条sql通过语法检查后,会在共享池里寻找是否有跟其相同的语句,如果有则用已有的执行计划执行sql语句,如果没有找到,则生成执行计划,然后才执行sql语句。可见,后者比前者多了额外的步骤,消耗了额外的CPU,并导致sql总体执行时间延长,而这里的关键就是“共享池中是否有相同的sql语句”。
String sql = "SELECT id,nick FROM user WHERE username=‘"+username+"‘";
以这样的方式传递到数据库中的sql为
假定这个语句是第一次执行,会生成执行计划。当变量发生变化时(username=”test_yy”),数据库又接收到这样的语句
Oracle不认为以上两条语句是相同的,因此又会生成执行计划,而这两者的执行计划是一样的(做了重复的工作)
2.导致共享池中的sql语句过多,加速SQL老化,造成共享池内部结构频繁维护。
如果一个某段程序未采用绑定变量的方式而又被大量调用,会导致共享池中不同的sql语句增多,而重用性极低,导致共享池内命中率下降。随着sql数量过多,一些语句逐渐老化,最终被清理出共享池。 而维护共享池内部结构要消耗大量的CPU和内存资源。
3、Sql注入漏洞
不采用绑定变量的方式可能会造成sql注入漏洞,本文仅仅通过示例说明为什么会造成sql注入漏洞,不对攻击方式、攻击类型等展开。以一个用户验证为例。
以上代码接收从客户端传来的username和password变量,在数据库中查询验证。假设攻击者从客户端传的username为任意值(如test)password变量为
1′ or ‘1′=’1
此时替换变量后的sql变为
这样得到的结果就是user表中的所有数据了。
4、使用绑定变量
以上两种问题的解决方式就是使用绑定变量,就是在sql语句里不直接写变量,而是用占位符,在执行时再把占位符替换为具体的变量值。代码片段如下
preparedStatement.setString(1,username);
preparedStatement.setString(2,password);
一些常用Jdbc工具对此进行了良好的封装,使代码更加简洁。比如Spring的SimpleJdbcTemplate
jdbcTemplate.queryForList(sql,username,password);
上面 ?的做占位符的形式被称为顺序占位符,在传参数值时必须注意顺序对应,还有一种是名称占位符。同样以SimpleJdbcTemplate为例说明.
map.put("pass",password);
map.put("name",username);
jdbcTemplate.queryForList(sql,map);
上面的例子中的:name和:pass就是名称占位符,在执行时sql时再绑定变量。
iBatis中有两种占位符,#name# 和$name$两种方式,需要注意的是前者会在执行sql时绑定变量,而后者直接是替换为变量值,所以后者仍然存在sql注入漏洞问题。
5、未尽话题
接口测试要不要检查sql注入漏洞问题?这个问题值得商榷,个人认为通过常规的用例设计检查sql注入漏洞恐怕不太可行(工作量太大效果不一定好),如果要做的话可借助(或自己开发)一些工具,通过扫描静态代码再人工排查的方式进行。另外如果这项工作进行的太细致,恐怕会跟安全测试的工作重叠太多,当然如果在测试过程中发现开发的代码存在sql注入漏洞(这往往跟开发者编码习惯有关)问题,一定不要放过,进行排查还是很有必要的。
转自:http://kb.cnblogs.com/page/55287/
郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。