您的位置：首页 > 数据库

参数化查询为什么能够防止SQL注入

2013-09-03 15:51 459 查看
很多人都知道SQL注入，也知道SQL参数化查询可以防止SQL注入，可为什么能防止注入却并不是很多人都知道的。

本文主要讲述的是这个问题，也许你在部分文章中看到过这块内容，当然了看看也无妨。

首先：我们要了解SQL收到一个指令后所做的事情：

具体细节可以查看文章：SqlServer编译、重编译与执行计划重用原理

在这里，我简单的表示为：收到指令->编译SQL生成执行计划->选择执行计划->执行执行计划。

具体可能有点不一样，但大致的步骤如上所示。

接着我们来分析为什么拼接SQL字符串会导致SQL注入的风险呢？

首先创建一张表Users:

CREATETABLE[dbo].[Users](

[Id][uniqueidentifier]NOTNULL,

[UserId][int]NOTNULL,

[UserName][varchar](50)NULL,

[Password][varchar](50)NOTNULL,

CONSTRAINT[PK_Users]PRIMARYKEYCLUSTERED

(

[Id]ASC

)WITH(PAD_INDEX=OFF,STATISTICS_NORECOMPUTE=OFF,IGNORE_DUP_KEY=OFF,ALLOW_ROW_LOCKS=ON,ALLOW_PAGE_LOCKS=ON)ON[PRIMARY]

)ON[PRIMARY]





插入一些数据：

INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),1,'name1','pwd1');
INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),2,'name2','pwd2');
INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),3,'name3','pwd3');
INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),4,'name4','pwd4');
INSERTINTO[Test].[dbo].[Users]([Id],[UserId],[UserName],[Password])VALUES(NEWID(),5,'name5','pwd5');


假设我们有个用户登录的页面，代码如下：

验证用户登录的sql如下：

selectCOUNT(*)fromUserswherePassword='a'andUserName='b'

这段代码返回Password和UserName都匹配的用户数量，如果大于1的话，那么就代表用户存在。

本文不讨论SQL中的密码策略，也不讨论代码规范，主要是讲为什么能够防止SQL注入，请一些同学不要纠结与某些代码，或者和SQL注入无关的主题。

可以看到执行结果：





这个是SQLprofile跟踪的SQL语句。





注入的代码如下：

selectCOUNT(*)fromUserswherePassword='a'andUserName='b'or1=1—'

这里有人将UserName设置为了“b'or1=1–”.

实际执行的SQL就变成了如下：









可以很明显的看到SQL注入成功了。

很多人都知道参数化查询可以避免上面出现的注入问题，比如下面的代码：

classProgram
{
privatestaticstringconnectionString="DataSource=.;InitialCatalog=Test;IntegratedSecurity=True";

staticvoidMain(string[]args)
{
Login("b","a");
Login("b'or1=1--","a");
}

privatestaticvoidLogin(stringuserName,stringpassword)
{
using(SqlConnectionconn=newSqlConnection(connectionString))
{
conn.Open();
SqlCommandcomm=newSqlCommand();
comm.Connection=conn;
//为每一条数据添加一个参数
comm.CommandText="selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName";
comm.Parameters.AddRange(
newSqlParameter[]{
newSqlParameter("@Password",SqlDbType.VarChar){Value=password},
newSqlParameter("@UserName",SqlDbType.VarChar){Value=userName},
});

comm.ExecuteNonQuery();
}
}
}


实际执行的SQL如下所示：

execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(1)',@Password='a',@UserName='b'

execsp_executesqlN'selectCOUNT(*)fromUserswherePassword=@PasswordandUserName=@UserName',N'@Passwordvarchar(1),@UserNamevarchar(11)',@Password='a',@UserName='b''or1=1—'




可以看到参数化查询主要做了这些事情：

1：参数过滤，可以看到@UserName='b''or1=1—'

2：执行计划重用


因为执行计划被重用，所以可以防止SQL注入。

首先分析SQL注入的本质，

用户写了一段SQL用来表示查找密码是a的，用户名是b的所有用户的数量。

通过注入SQL，这段SQL现在表示的含义是查找(密码是a的，并且用户名是b的，)或者1=1的所有用户的数量。

可以看到SQL的语意发生了改变，为什么发生了改变呢？，因为没有重用以前的执行计划，因为对注入后的SQL语句重新进行了编译，因为重新执行了语法解析。所以要保证SQL语义不变，即我想要表达SQL就是我想表达的意思，不是别的注入后的意思，就应该重用执行计划。

如果不能够重用执行计划，那么就有SQL注入的风险，因为SQL的语意有可能会变化，所表达的查询就可能变化。

在SQLServer中查询执行计划可以使用下面的脚本：

DBCCFreeProccache

selecttotal_elapsed_time/execution_count平均时间,total_logical_reads/execution_count逻辑读,
usecounts重用次数,SUBSTRING(d.text,(statement_start_offset/2)+1,
((CASEstatement_end_offset
WHEN-1THENDATALENGTH(text)
ELSEstatement_end_offsetEND
-statement_start_offset)/2)+1)语句执行fromsys.dm_exec_cached_plansa
crossapplysys.dm_exec_query_plan(a.plan_handle)c
,sys.dm_exec_query_statsb
crossapplysys.dm_exec_sql_text(b.sql_handle)d
--wherea.plan_handle=b.plan_handleandtotal_logical_reads/execution_count>4000
ORDERBYtotal_elapsed_time/execution_countDESC;






博客园有篇文章：SqlServer参数化查询之wherein和like实现详解

在这篇文章中有这么一段：





这里作者有一句话：”不过这种写法和直接拼SQL执行没啥实质性的区别”

任何拼接SQL的方式都有SQL注入的风险，所以如果没有实质性的区别的话，那么使用exec动态执行SQL是不能防止SQL注入的。

比如下面的代码：

privatestaticvoidTestMethod()
{
using(SqlConnectionconn=newSqlConnection(connectionString))
{
conn.Open();
SqlCommandcomm=newSqlCommand();
comm.Connection=conn;
//使用exec动态执行SQL　
//实际执行的查询计划为(@UserIDvarchar(max))select*fromUsers(nolock)whereUserIDin(1,2,3,4)　　
//不是预期的(@UserIDvarchar(max))exec('select*fromUsers(nolock)whereUserIDin('+@UserID+')')
comm.CommandText="exec('select*fromUsers(nolock)whereUserIDin('+@UserID+')')";
comm.Parameters.Add(newSqlParameter("@UserID",SqlDbType.VarChar,-1){Value="1,2,3,4"});
//comm.Parameters.Add(newSqlParameter("@UserID",SqlDbType.VarChar,-1){Value="1,2,3,4);deletefromUsers;--"});
comm.ExecuteNonQuery();
}
}


执行的SQL如下：

execsp_executesqlN'exec(''select*fromUsers(nolock)whereUserIDin(''+@UserID+'')'')',N'@UserIDvarchar(max)',@UserID='1,2,3,4'





可以看到SQL语句并没有参数化查询。


如果你将UserID设置为”

1,2,3,4);deletefromUsers;—-

”,那么执行的SQL就是下面这样：

execsp_executesqlN'exec(''select*fromUsers(nolock)whereUserIDin(''+@UserID+'')'')',N'@UserIDvarchar(max)',@UserID='1,2,3,4);deletefromUsers;--'


不要以为加了个@UserID就代表能够防止SQL注入，实际执行的SQL如下：





任何动态的执行SQL都有注入的风险，因为动态意味着不重用执行计划，而如果不重用执行计划的话，那么就基本上无法保证你写的SQL所表示的意思就是你要表达的意思。


这就好像小时候的填空题，查找密码是(____)并且用户名是(____)的用户。

不管你填的是什么值，我所表达的就是这个意思。


最后再总结一句：因为参数化查询可以重用执行计划，并且如果重用执行计划的话，SQL所要表达的语义就不会变化，所以就可以防止SQL注入,如果不能重用执行计划，就有可能出现SQL注入，
存储过程也是一样的道理，因为可以重用执行计划。

                                            

                                        

                        
                        内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 点击这里给我发消息 
                    

                    

                    

                        

                         标签： 
                                                

                        

                    


                

            


            

                
相关文章推荐

                

                
            

        

        

            

            
            

                

                    
新的分享

                    

                        
                    

                

            


            

                

                    
章节导航