㈠ 參數化查詢為什麼能夠防止sql注入
比如一個請求帶參數，我們不使用參數化查詢，那麼他在url後面接上 or 1=1那麼所有的記錄都會出現，這么資料庫就不安全。
參數化查詢可以防止這種注入，綁定sql語句的對應列的值，不會出現上面這種情況。
㈡ 如何能防止sql注入
如何能防止sql注入
普通用戶與系統管理員用戶的許可權要有嚴格的區分。
如果一個普通用戶在使用查詢語句中嵌入另一個Drop Table語句，那麼是否允許執行呢?由於Drop語句關繫到資料庫的基本對象，故要操作這個語句用戶必須有相關的許可權。在許可權設計中，對於終端用戶，即應用軟體的使用者，沒有必要給他們資料庫對象的建立、刪除等許可權。那麼即使在他們使用SQL語句中帶有嵌入式的惡意代碼，由於其用戶許可權的限制，這些代碼也將無法被執行。故應用程序在設計的時候，
強迫使用參數化語句。
如果在編寫SQL語句的時候，用戶輸入的變數不是直接嵌入到SQL語句。而是通過參數來傳遞這個變數的話，那麼就可以有效的防治SQL注入式攻擊。也就是說，用戶的輸入絕對不能夠直接被嵌入到SQL語句中。與此相反，用戶的輸入的內容必須進行過濾，或者使用參數化的語句來傳遞用戶輸入的變數。參數化的語句使用參數而不是將用戶輸入變數嵌入到SQL語句中。採用這種措施，可以杜絕大部分的SQL注入式攻擊。不過可惜的是，現在支持參數化語句的資料庫引擎並不多。不過資料庫工程師在開發產品的時候要盡量採用參數化語句。
多多使用SQL Server資料庫自帶的安全參數。
為了減少注入式攻擊對於SQL Server資料庫的不良影響，在SQLServer資料庫專門設計了相對安全的SQL參數。在資料庫設計過程中，工程師要盡量採用這些參數來杜絕惡意的SQL注入式攻擊。
如在SQL Server資料庫中提供了Parameters集合。這個集合提供了類型檢查和長度驗證的功能。如果管理員採用了Parameters這個集合的話，則用戶輸入的內容將被視為字元值而不是可執行代碼。即使用戶輸入的內容中含有可執行代碼，則資料庫也會過濾掉。因為此時資料庫只把它當作普通的字元來處理。使用Parameters集合的另外一個優點是可以強制執行類型和長度檢查，范圍以外的值將觸發異常。如果用戶輸入的值不符合指定的類型與長度約束，就會發生異常，並報告給管理員。如上面這個案例中，如果員工編號定義的數據類型為字元串型，長度為10個字元。而用戶輸入的內容雖然也是字元類型的數據，但是其長度達到了20個字元。則此時就會引發異常，因為用戶輸入的內容長度超過了資料庫欄位長度的限制。
加強對用戶輸入的驗證。
總體來說，防治SQL注入式攻擊可以採用兩種方法，一是加強對用戶輸入內容的檢查與驗證;二是強迫使用參數化語句來傳遞用戶輸入的內容。在SQLServer資料庫中，有比較多的用戶輸入內容驗證工具，可以幫助管理員來對付SQL注入式攻擊。測試字元串變數的內容，只接受所需的值。拒絕包含二進制數據、轉義序列和注釋字元的輸入內容。這有助於防止腳本注入，防止某些緩沖區溢出攻擊。測試用戶輸入內容的大小和數據類型，強制執行適當的限制與轉換。這即有助於防止有意造成的緩沖區溢出，對於防治注入式攻擊有比較明顯的效果。
如可以使用存儲過程來驗證用戶的輸入。利用存儲過程可以實現對用戶輸入變數的過濾，如拒絕一些特殊的符號。如以上那個惡意代碼中，只要存儲過程把那個分號過濾掉，那麼這個惡意代碼也就沒有用武之地了。在執行SQL語句之前，可以通過資料庫的存儲過程，來拒絕接納一些特殊的符號。在不影響資料庫應用的前提下，應該讓資料庫拒絕包含以下字元的輸入。如分號分隔符，它是SQL注入式攻擊的主要幫凶。如注釋分隔符。注釋只有在數據設計的時候用的到。一般用戶的查詢語句中沒有必要注釋的內容，故可以直接把他拒絕掉，通常情況下這么做不會發生意外損失。把以上這些特殊符號拒絕掉，那麼即使在SQL語句中嵌入了惡意代碼，他們也將毫無作為。
故始終通過測試類型、長度、格式和范圍來驗證用戶輸入，過濾用戶輸入的內容。這是防止SQL注入式攻擊的常見並且行之有效的措施。
多層環境如何防治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;
㈣ c# 傳參的方式能完全防止sql注入嗎
結論：如果不能夠重用執行計劃，那麼就有SQL注入的風險，因為SQL的語意有可能會變化，所表達的查詢就可能變化。
首先，什麼是注入漏洞攻擊呢？所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。通常的解決方案有過濾敏感字元，比如說過濾掉or, and , select sql等關鍵字，通過參數化查詢解決sql注入漏洞的實例。
所謂的參數化查詢（Parameterized Query 或 Parameterized Statement）是指在設計與資料庫鏈接並訪問數據時，在需要填入數值或數據的地方，使用參數 (Parameter) 來給值，這個方法目前已被視為最有效可預防SQL注入攻擊 (SQL Injection) 的攻擊手法的防禦方式。Microsoft SQL Server 的參數格式是以 "@" 字元加上參數名稱而成.
SQL 引擎的處理流程，大致為：收到指令 -> 編譯SQL生成執行計劃 ->選擇執行計劃 ->執行執行計劃。
參數化查詢主要做了這些事情：
1：參數過濾，對傳入值進行了處理，按字元語義來處理。
2：執行計劃重用
為參數化查詢可以重用執行計劃，並且如果重用執行計劃的話，SQL所要表達的語義就不會變化，所以就可以防止SQL注入,如果不能重用執行計劃，就有可能出現SQL注入，存儲過程也是一樣的道理，因為可以重用執行計劃。
㈤ 參數化查詢為什麼能夠防止SQL注入
因為參數化查詢限制了條件的數據類型，可以有效的防止惡意的字元串拼接
㈥ 什麼是SQL語句注入該如何防止數據SQL數據注入
sql 注入:
就是通過表單將包含sql命令的信息發送至後台，後台將這些信息按照sql命令的方式，得到運行，那麼我們稱這種行為為sql注入。
如下所示:sql注入漏洞防止方法
參數化是目前sql注入防止的最佳方法。
請參閱，如有疑問，請及時溝通！
㈦ 如何防止sql注入攻擊
1，避免將用戶提供的輸入直接放入SQL語句中，最好使用准備好的語句和參數化查詢，這樣更加安全。
2，不要將敏感數據保存在純文本中，加密存儲在資料庫中的私有或機密數據，這樣可以提供另一級保護，以防止攻擊者成功地排出敏感數據。
3，將資料庫用戶的功能設置為最低要求，這將限制攻擊者在設法獲取訪問許可權時可以執行的操作。
4，避免直接向用戶顯示資料庫錯誤，攻擊者可以使用這些錯誤消息來獲取有關資料庫的信息。
5，對訪問資料庫的Web應用程序使用防火牆，這樣可以為面向Web的應用程序提供保護，可以幫助識別SQL注入嘗試;根據設置，還可以幫助防止SQL注入嘗試到達應用程序。
6，定期測試與資料庫交互的Web應用程序，這樣做可以幫助捕獲可能允許SQL注入的新錯誤或回歸。
7，將資料庫更新為最新的可用修補程序，這可以防止攻擊者利用舊版本中存在的已知弱點或錯誤。
㈧ 參數化查詢為什麼能夠防止SQL注入
簡單的例子：
select * from A where id=?
我傳個參數，'1;select * from B',如果是非參數化，執行語句是：
select * from A where id=1;select * from B
會執行兩句sql，容易sql注入，但如果是參數化，執行語句：
select * from A where id='1;select * from B'
這樣，'1;select * from B'其實就是sql語句的一個參數，不會改變語法
㈨ 參數化查詢為什麼能夠防止SQL注入
參數化查詢主要做了這些事情：
1：參數過濾
2：執行計劃重用
因為參數化查詢可以重用執行計劃，並且如果重用執行計劃的話，SQL所要表達的語義就不會變化，所以就可以防止SQL注入,如果不能重用執行計劃，就有可能出現SQL注入，存儲過程也是一樣的道理，因為可以重用執行計劃。
㈩ 什麼是SQL注入，如何防止SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．x0dx0a防護x0dx0a歸納一下，主要有以下幾點：x0dx0a1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和x0dx0a雙"-"進行轉換等。x0dx0a2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。x0dx0a3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。x0dx0a4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。x0dx0a5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝x0dx0a6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky，網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS攻擊等。