很多人（rén）都知道SQL注入，也知（zhī）道SQL參（cān）數化查詢可以防止SQL注入（rù），可（kě）為（wéi）什麽能防止注入卻並（bìng）不是很（hěn）多人都知道的。本文主要講述（shù）的是這個（gè）問題，也（yě）許你在部分文章中（zhōng）看到過這塊內容，當（dāng）然了看看也無妨。

首先：我們要了解SQL收到一個指（zhǐ）令後所做的事情：

具體細節可以查看文（wén）章：Sql Server 編譯、重編譯與執行（háng）計劃重用原理，在這裏（lǐ），我簡單的表示為： 收到指令 -> 編譯SQL生成執行計劃 ->選擇執行計劃 ->執（zhí）行執行計劃。

具體（tǐ）可能有（yǒu）點不一樣，但大致的步驟如上所示。接著我們（men）來分析為什麽拚接SQL 字符（fú）串會導致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]

插入（rù）一些數據：

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');

假設我們有個用（yòng）戶登錄的（de）頁麵，代碼如下：

驗證用戶登錄的sql 如下：

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

這段代碼返回Password 和UserName都匹配的用（yòng）戶數量，如果大於1的話，那麽就代表用戶存在。

本文不討論SQL 中的密（mì）碼策略，也不討論代碼（mǎ）規範，主要是講為什麽能夠防止SQL注入，請一些同學（xué）不要糾結與某些代碼，或者和SQL注入無關的主題。

可以看（kàn）到（dào）執行結果：

這個是SQL profile 跟（gēn）蹤的SQL 語句。

注入的代碼如下：

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

這裏（lǐ）有人將UserName設置（zhì）為了（le） “b' or 1=1 –”.

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

可以很（hěn）明（míng）顯的（de）看到SQL注入成功（gōng）了。

很多人都知道參數（shù）化查詢可以避免上麵出（chū）現的注入問題，比如下麵的代碼：

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;
            //為每一條數（shù）據添加一個參數
            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 如（rú）下所示：

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—' 

可以看到參數化查詢主要（yào）做了這些事情：

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

2：執（zhí）行（háng）計劃重用（yòng）

因（yīn）為執行計劃被重用（yòng），所以可以防止SQL注入。

首先分析SQL注入的本質，用戶寫（xiě）了一段SQL 用來表示查找密碼是a的，用戶名是b的所有用戶的數量（liàng）。通過注入SQL，這段SQL現在表示的含義是查找(密碼是a的，並且（qiě）用戶（hù）名是b的，) 或者1=1 的所（suǒ）有用戶的數量。

可（kě）以看到SQL的語意發生了改變，為什麽（me）發生了改變（biàn）呢？，因為沒有重用以前的執行計劃，因為對注入後的（de）SQL語句（jù）重新進行了編譯，因（yīn）為重新執行了語法解析。所以要保證SQL語義不變，即我想要表達SQL就是我想表達的意思，不是（shì）別的注入後的（de）意思，就應該重用（yòng）執行計劃。

如果不（bú）能夠重（chóng）用執行計劃，那麽就有SQL注入的風險，因為SQL的語意有可能會變化，所表（biǎo）達的查詢就可能變化。

在SQL Server 中查詢執行計（jì）劃可以使用下麵的腳本（běn）：

DBCC FreeProccacheselect 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) 語句執（zhí）行 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;

在這篇（piān）文章中有這麽一段（duàn）：

這裏作者有一（yī）句（jù）話：”不過這種寫法（fǎ）和直接拚SQL執行沒啥實質性的（de）區別”，任何拚接SQL的（de）方式都有（yǒu）SQL注（zhù）入的風險，所以如果沒有實質性的區別的話，那麽使用exec 動態執行SQL是不能防止SQL注入的。

比如下麵的代碼（mǎ）：

private static void TestMethod()
{
    using (SqlConnection conn = new SqlConnection(connectionString))
    {
        conn.Open();
        SqlCommand comm = new SqlCommand();
        comm.Connection = conn;
        //使（shǐ）用（yòng）exec動態執行SQL　
        //實際執行（háng）的查詢計劃為(@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();