Ⅰ 參數化查詢為什麼能夠防止sql注入
因為參數化查詢限制了條件的數據類型，可以有效的防止惡意的字元串拼接
Ⅱ 參數化查詢為什麼能夠防止SQL注入
很多人都知道SQL注入，也知道SQL參數化查詢可以防止SQL注入，可為什麼能防止注入卻並不是很多人都知道的。
本文主要講述的是這個問題，也許你在部分文章中看到過這塊內容，當然了看看也無妨。
首先：我們要了解SQL收到一個指令後所做的事情：
具體細節可以查看文章：Sql Server 編譯、重編譯與執行計劃重用原理
在這里，我簡單的表示為： 收到指令 -> 編譯SQL生成執行計劃 ->選擇執行計劃 ->執行執行計劃。
http://www.cnblogs.com/LoveJenny/archive/2013/01/15/2860553.html
詳細可以參考這個，有圖解教程，希望可以幫到你
Ⅲ 為什麼參數化查詢可以防止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注入
簡單來說，參數里的內容都會被當作文本來處，而不是SQL語句中一部分。
Ⅳ mybatis 為什麼可以防止sql注入
因為在mybatis中，」${xxx}」這樣格式的參數會直接參與sql編譯，從而不能避免注入攻擊。但涉及到動態表名和列名時，只能使用「${xxx}」這樣的參數格式，所以，這樣的參數需要程序開發者在代碼中手工進行處理來防止注入。
#xxx# 代表xxx是屬性值,map裡面的key或者是你的pojo對象裡面的屬性, ibatis會自動在它的外面加上引號,表現在sql語句是這樣的 where xxx = 'xxx' ;
$xxx$ 則是把xxx作為字元串拼接到sql語句中, 比如 order by topicId , 語句這樣寫 ... order by #xxx# ibatis 就會翻譯成order by 'topicId' （這樣就會報錯） 語句這樣寫 ... order by $xxx$ ibatis 就會翻譯成 order by topicId
#將傳入的數據都當成一個字元串，會對自動傳入的數據加一個雙引號。如：order by #user_id#，如果傳入的值是111,那麼解析成sql時的值為order by "111", 如果傳入的值是id，則解析成的sql為order by "id".2. $將傳入的數據直接顯示生成在sql中。如：order by $user_id$，如果傳入的值是111,那麼解析成sql時的值為order by user_id, 如果傳入的值是id，則解析成的sql為order by id
所以說#方式能夠很大程度防止sql注入。
Ⅵ 參數化查詢為什麼能夠防止SQL注入
如果使用.net，那就簡單了，可以用ADO.NET的參數化查詢。
例如:
SqlCommand cmd=new SqlCommand("SELECT * FROM test WHERE id=@id",conn);
cmd.Parameters.AddWithValue("@id",sid);
cmd.ExecuteNonQuery();
這個有很多種用法，詳細的內容需要對離線資料庫的概念進行理解
Ⅶ 參數化查詢為什麼能夠防止SQL注入
比如一個請求帶參數，我們不使用參數化查詢，那麼他在url後面接上 or 1=1那麼所有的記錄都會出現，這么資料庫就不安全。
參數化查詢可以防止這種注入，綁定sql語句的對應列的值，不會出現上面這種情況。
Ⅷ c# 傳參的方式能完全防止sql注入嗎
參數化sql語句完全能夠防止sql注入，我說得是完全。不必再過濾什麼了。
參數化sql是直接生成sql資料庫查詢底層的參數，而不是通過編譯器和解釋器根據sql語句自動分詞，確定參數的值（這樣容易被騙）。
比如：select 姓名 from 基本信息 where 學號='18'，客戶構造sql語句：select 學號 from 基本信息 where 學號='' or '1'='1'，sql資料庫系統編譯解釋為：
1.這是一條select語句；
2。操作的表為「基本信息」；
3。返回欄位為「姓名」；
4。條件為學號='' or '1'='1'
5。學號的參數為''。
這樣就被騙了。
而採用參數化方法，select 學號 from 基本信息 where 學號=@studentID，參數@studentID=' or '1'='
最後編譯解釋為select 學號 from 基本信息 where 學號="' or '1'='"
相當於在參數@studentID的值的外面加上了一個看不見的""，所以無論對方構造的如何巧妙，都無法注入。