sql注入

http://www.cnblogs.com/LoveJenny/archive/2013/01/15/2860553.html

http://www.cnblogs.com/lzrabbit/archive/2012/04/22/2465313.html

不少人都知道SQL注入，也知道SQL參數化查詢能夠防止SQL注入，可爲何能防止注入卻並非不少人都知道的。

本文主要講述的是這個問題，也許你在部分文章中看到過這塊內容，固然了看看也無妨。

 

首先：咱們要了解SQL收到一個指令後所作的事情：

具體細節能夠查看文章：Sql Server 編譯、重編譯與執行計劃重用原理

在這裏，我簡單的表示爲： 收到指令 -> 編譯SQL生成執行計劃 ->選擇執行計劃 ->執行執行計劃。

具體可能有點不同，但大體的步驟如上所示。

 

接着咱們來分析爲何拼接SQL 字符串會致使SQL注入的風險呢？

首先建立一張表Users:

CREATE TABLE [dbo].[Users]( [Id] [uniqueidentifier] NOT NULL, [UserId] [int] NOT NULL, [UserName] [varchar](50) NULL, [Password] [varchar](50) NOT NULL, CONSTRAINT [PK_Users] PRIMARY KEY CLUSTERED ( [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]

 

插入一些數據：

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

 

假設咱們有個用戶登陸的頁面，代碼以下：

驗證用戶登陸的sql 以下：

select COUNT(*) from Users where Password = 'a' and UserName = 'b' 

這段代碼返回Password 和UserName都匹配的用戶數量，若是大於1的話，那麼就表明用戶存在。

本文不討論SQL 中的密碼策略，也不討論代碼規範，主要是講爲何可以防止SQL注入，請一些同窗不要糾結與某些代碼，或者和SQL注入無關的主題。

 

 

能夠看到執行結果：

這個是SQL profile 跟蹤的SQL 語句。

 

注入的代碼以下：

select COUNT(*) from Users where Password = 'a' and UserName = 'b' or 1=1—'

這裏有人將UserName設置爲了 「b' or 1=1 –」.

 

實際執行的SQL就變成了以下：

 

  能夠很明顯的看到SQL注入成功了。

 

不少人都知道參數化查詢能夠避免上面出現的注入問題，好比下面的代碼：

class Program
{
    private static string connectionString = "Data Source=.;Initial Catalog=Test;Integrated Security=True"; static void Main(string[] args) { Login("b", "a"); Login("b' or 1=1--", "a"); } private static void Login(string userName, string password) { using (SqlConnection conn = new SqlConnection(connectionString)) { conn.Open(); SqlCommand comm = new SqlCommand(); comm.Connection = conn; //爲每一條數據添加一個參數 comm.CommandText = "select COUNT(*) from Users where Password = @Password and UserName = @UserName"; comm.Parameters.AddRange( new SqlParameter[]{ new SqlParameter("@Password", SqlDbType.VarChar) { Value = password}, new SqlParameter("@UserName", SqlDbType.VarChar) { Value = userName}, }); comm.ExecuteNonQuery(); } } }

 

實際執行的SQL 以下所示：

exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(1)',@Password='a',@UserName='b'

exec sp_executesql N'select COUNT(*) from Users where Password = @Password and UserName = @UserName',N'@Password varchar(1),@UserName varchar(11)',@Password='a',@UserName='b'' or 1=1—'

能夠看到參數化查詢主要作了這些事情：

1：參數過濾，能夠看到 @UserName='b'' or 1=1—'

2：執行計劃重用

 

由於執行計劃被重用，因此能夠防止SQL注入。

 

首先分析SQL注入的本質，

用戶寫了一段SQL 用來表示查找密碼是a的，用戶名是b的全部用戶的數量。

經過注入SQL，這段SQL如今表示的含義是查找(密碼是a的，而且用戶名是b的，) 或者1=1 的全部用戶的數量。

 

能夠看到SQL的語意發生了改變，爲何發生了改變呢？，由於沒有重用之前的執行計劃，由於對注入後的SQL語句從新進行了編譯，由於從新執行了語法解析。因此要保證SQL語義不變，即我想要表達SQL就是我想表達的意思，不是別的注入後的意思，就應該重用執行計劃。

 

若是不可以重用執行計劃，那麼就有SQL注入的風險，由於SQL的語意有可能會變化，所表達的查詢就可能變化。

 

在SQL Server 中查詢執行計劃可使用下面的腳本：

DBCC FreeProccache

select total_elapsed_time / execution_count 平均時間,total_logical_reads/execution_count 邏輯讀, usecounts 重用次數,SUBSTRING(d.text, (statement_start_offset/2) + 1, ((CASE statement_end_offset WHEN -1 THEN DATALENGTH(text) ELSE statement_end_offset END - statement_start_offset)/2) + 1) 語句執行 from sys.dm_exec_cached_plans a cross apply sys.dm_exec_query_plan(a.plan_handle) c ,sys.dm_exec_query_stats b cross apply sys.dm_exec_sql_text(b.sql_handle) d --where a.plan_handle=b.plan_handle and total_logical_reads/execution_count>4000 ORDER BY total_elapsed_time / execution_count DESC;

 

博客園有篇文章： Sql Server參數化查詢之where in和like實現詳解

 

在這篇文章中有這麼一段：

 

這裏做者有一句話：」不過這種寫法和直接拼SQL執行沒啥實質性的區別」

任何拼接SQL的方式都有SQL注入的風險，因此若是沒有實質性的區別的話，那麼使用exec 動態執行SQL是不能防止SQL注入的。

 

好比下面的代碼：

private static void TestMethod()
{
    using (SqlConnection conn = new SqlConnection(connectionString)) { conn.Open(); SqlCommand comm = new SqlCommand(); comm.Connection = conn; //使用exec動態執行SQL　 //實際執行的查詢計劃爲(@UserID varchar(max))select * from Users(nolock) where UserID in (1,2,3,4)　　 //不是預期的(@UserID varchar(max))exec('select * from Users(nolock) where UserID in ('+@UserID+')') comm.CommandText = "exec('select * from Users(nolock) where UserID in ('+@UserID+')')"; comm.Parameters.Add(new SqlParameter("@UserID", SqlDbType.VarChar, -1) { Value = "1,2,3,4" }); //comm.Parameters.Add(new SqlParameter("@UserID", SqlDbType.VarChar, -1) { Value = "1,2,3,4); delete from Users;--" }); comm.ExecuteNonQuery(); } }

 

執行的SQL 以下：

exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4'

能夠看到SQL語句並無參數化查詢。

若是你將UserID設置爲」

1,2,3,4); delete from Users;—-

」,那麼執行的SQL就是下面這樣：

exec sp_executesql N'exec(''select * from Users(nolock) where UserID in (''+@UserID+'')'')',N'@UserID varchar(max) ',@UserID='1,2,3,4); delete from Users;--'

 

不要覺得加了個@UserID 就表明可以防止SQL注入，實際執行的SQL 以下：

 

任何動態的執行SQL 都有注入的風險，由於動態意味着不重用執行計劃，而若是不重用執行計劃的話，那麼就基本上沒法保證你寫的SQL所表示的意思就是你要表達的意思。

這就好像小時候的填空題，查找密碼是(____) 而且用戶名是(____)的用戶。

無論你填的是什麼值，我所表達的就是這個意思。

最後再總結一句：由於參數化查詢能夠重用執行計劃，而且若是重用執行計劃的話，SQL所要表達的語義就不會變化，因此就能夠防止SQL注入,若是不能重用執行計劃，就有可能出現SQL注入，存儲過程也是同樣的道理，由於能夠重用執行計劃。