SQL注入原理及PreparedStatement的使用

SQL注射原理

SQL 注射能使攻击者绕过认证机制，完全控制远程服务器上的数据库。SQL是结构化查询语言的简称，它是访问数据库的事实标准。目前，大多数Web应用都使用 SQL数据库来存放应用程序的数据。几乎所有的Web应用在后台都使用某种SQL数据库。跟大多数语言一样，SQL语法允许数据库命令和用户数据混杂在一 起的。如果开发人员不细心的话，用户数据就有可能被解释成命令，这样的话，远程用户就不仅能向Web应用输入数据，而且还可以在数据库上执行任意命令了。

登陆验证

现 在以一个需要用户身份认证的简单的Web应用程序为例进行讲解。假定这个应用程序提供一个登录页面，要求用户输入用户名和口令。用户通过HTTP请求发送 他们的用户名和口令，之后，Web应用程序检查用户传递来用户名和口令跟数据库中的用户名和口令是否匹配。这种情况下，会要求在SQL数据库中使用一个数 据库表。

对一个用户进行认证，实际上就是将用户的输入即用户名和口令跟表中的各行进行比较，如果跟某行中的用户名和口令跟用户的输入完全匹配，那么该用户就会通过认证。

假如后台的sql语句时这样拼接的

select id from test where username='"+myname+"' and password='"+mypasswd+"' ";

表面上看，如果用户名和口令对匹配，那么该用户通过认证；否则，该用户不会通过认证——但是，事实果真如此吗？非也！读者也许已经注意到了，这里并没有对SQL命令进行设防，所以 攻击者完全能够在用户名或者口令字段中注入SQL语句，从而改变SQL查询  。为此，我们仔细研究一下上面的SQL查询字符串:

上述代码认为字符串username和password都是数据，不过，攻击者却可以随心所欲地输入任何字符  。如果一位攻击者输入的用户名为

’OR1=1—

而口令为

x

双划符号--告诉SQL解析器，右边的东西全部是注释，所以不必理会。这样，查询字符串相当于：

select  id from test where username='' or 1=1;

如 今的SELECT语句跟以前的已经大相径庭了，因为现在只要用户名为长度为零的字符串''或1=1这两个条件中一个为真，就返回用户标识符ID——我们知 道，1=1是恒为真的。所以这个语句将返回user_table中的所有ID。在此种情况下，攻击者在username字段放入的是SQL指令 'OR1=1--而非数据。

更为严重的情况是当username对应的是'OR1=1;DROPTABLEuser_table;--

数据库中执行的sql语句就变成了：

select id from test where username='' or 1=1;drop table test

这个语句将执行句法上完全正确的SELECT语句，并利用drop命令清空test表。

应对策略

问题的关键就是不要用string构造sql语句，这样就不会利用输入的参数构造sql语句了。所以要用PreparedStatement替换Statement，即用占位符作为实参定义sql语句，从而避免sql注入攻击。

不管什么框架，还是纯JDBC，只用Preparedstatement,一定要用占位符作为实参来构造sql（或hql）语句。

 

String sql=   "select * from test where usernmae=? and password=? "  ;
PreparedStatement psm=conn.preparedStatement(sql);
psm.setString(1,myname);
psm.setString(2,mypasswd);
Result rs=psm.executeQuery();  
if  (rs.next){
rs.close();
con.close();
return   false  ;
}
else  {
rs.close();
con.close();
return   true  ;
}

一条效率差的sql语句,足以毁掉整个应用.

Statement是PreparedStatement的父接口,不进行预编译操作,减少了进行预编译的开销.单次运行PreparedStatement要比Statement要慢一些. 
PreparedStatement可以实现Statement的所有功能,但是之所以叫它预编译指令,是因为在创建它的一个对象时可以给定具有一定格式的SQL字符串,然后用它的setXXX方法给指定的SQL语句以填空的方式赋值,具有这样的特性后,它在多次执行一条固定格式的字符串时就很方便,也更效率.不像Statement那样每次执行都要先编译字符串在执行SQL了.

PreparedStatement需要服务器端的支持来提高效率.比如在Oracle上就会有显著效果,而MySQL明确地说明了不支持PreparedStatement.
Oracle中会将所有的SQL语句先编译,叫做"执行计划",放在Oracle内部的一个特定的缓存中,每次遇到相同的SQL,就会先调用缓存中的,如果不预编译,每次都用Statement,那么每次都要编译,在缓冲中会有很多重复的"执行计划"影响数据库的性能.还有一点就是在使用setObject()的时候,记得一定要使用带targetSqlType参数的方法,来提高效率.

SQL注入攻击是利用设计上的漏洞,在目标服务器上运行SQL语句进行攻击,动态生成SQL语句时没有对用户输入的数据进行验证是SQL注入攻击得逞的主要原因.
对于JDBC而言,SQL注入攻击只对Statement有效,对PreparedStatement是无效的,这是因为PreparedStatement不允许在插入时改变查询的逻辑结构.
绕过验证,但这种手段只对Statement有效,对PreparedStatement无效.

如果有一条SQL语句: "select * from 表 where 用户名 = '用户名'"
Statement的SQL语句是这样写的: "select * from 表 where 用户名 = '"+ 变量值 +"'"
PreparedStatement的SQL语句是这样写的: "select * from 表 where 用户名 = ?" 然后对应?赋值
这样我们就发现输入 "aa' or '1' = '1"
Statement是将这个和SQL语句做字符串连接到一起执行
PreparedStatement是将 "aa' or '1' = '1" 作为一个字符串赋值给?,做为"用户名"字段的对应值,显然这样SQL注入无从谈起了.

实现机制不同,注入只对SQL语句的准备(编译)过程有破坏作用,而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,不再需要对SQL语句进行解析,准备,因此也就避免了SQL注入问题.

引自：http://blog.csdn.net/maxracer/article/details/6118036