一、概括介紹
要對網站安全性進行測試，就必須學習了一些sql注入的知識。
網上有許多關于網站安全性測試的文檔，有一些是關于sql注入的，比如對網站的輸入框進行一些測試，在輸入框中輸入alter("abc"),但是輸入框有字元限制，隻輸入,結果網站出現了問題。
另一個就是在URL最後随意輸入一些字元或數字，結果，某個子產品出現了問題，暴露了網站的一些資訊。 是以，SQL注入對于網站安全性有很重要的影響，SQL注入方面的知識有：
SQL注入是一種攻擊方式，在這種攻擊方式中，惡意代碼被插入到字元串中，然後将該字元串傳遞到SQL
Server的執行個體以進行分析和執行。任何構成SQL語句的過程都應進行注入漏洞檢查，因為SQL
Server将執行其接收到的所有文法有效的查詢。一個有經驗的、堅定的攻擊者甚至可以操作參數化資料。
SQL注入的主要形式包括直接将代碼插入到與SQL指令串聯在一起并使其得以執行的使用者輸入變量。一種間接的攻擊會将惡意代碼注入要在表中存儲或作為中繼資料存儲的字元串。在存儲的字元串随後串連到一個動态SQL指令中時，将執行該惡意代碼。
注入過程的工作方式是提前終止文本字元串，然後追加一個新的指令。由于插入的指令可能在執行前追加其他字元串，是以攻擊者将用注釋标記“--”來終止注入的字元串。執行時，此後的文本将被忽略。
以下腳本顯示了一個簡單的SQL注入。此腳本通過串聯寫死字元串和使用者輸入的字元串而生成一個SQL查詢：
var Shipcity;
ShipCity = Request.form.
("ShipCity");
var sql = "select * from
OrdersTable where ShipCity = '" + ShipCity + "'";
使用者将被提示輸入一個市縣名稱。如果使用者輸入Redmond，則查詢将由與下面内容相似的腳本組成：
SELECT * FROM OrdersTable WHERE
ShipCity = 'Redmond'
但是，假定使用者輸入以下内容：
Redmond'; drop table
OrdersTable--
此時，腳本将組成以下查詢：
SELECT * FROM OrdersTable WHERE
ShipCity = 'Redmond';drop table OrdersTable--'
分号(;)表示一個查詢的結束和另一個查詢的開始。雙連字元(--)訓示目前行餘下的部分是一個注釋，應該忽略。如果修改後的代碼文法正确，則伺服器将執行該代碼。SQL
Server處理該語句時，SQL
Server将首先選擇OrdersTable中的所有記錄(其中ShipCity為Redmond)。然後，SQL
Server将删除OrdersTable。
隻要注入的SQL代碼文法正确，便無法采用程式設計方式來檢測篡改。是以，必須驗證所有使用者輸入，并仔細檢查在您所用的伺服器中執行構造SQL指令的代碼。本主題中的以下各部分說明了編寫代碼的最佳做法。
驗證所有輸入:
始終通過測試類型、長度、格式和範圍來驗證使用者輸入。實作對惡意輸入的預防時，請注意應用程式的體系結構和部署方案。請注意，設計為在安全環境中運作的程式可能會被複制到不安全的環境中。以下建議應被視為最佳做法：
如果一個使用者在需要郵政編碼的位置無意中或惡意地輸入了一個10
MB的MPEG檔案，應用程式會做出什麼反應？
如果在文本字段中嵌入了一個DROP
TABLE語句，應用程式會做出什麼反應？
測試輸入的大小和資料類型，強制執行适當的限制。這有助于防止有意造成的緩沖區溢出。
輸入字元
在Transact-SQL中的含義
; 查詢分隔符。
' 字元資料字元串分隔符。
-- 注釋分隔符。
注釋分隔符。伺服器不對之間的注釋進行處理。
xp_
用于目錄擴充存儲過程的名稱的開頭，如xp_cmdshell。
二、如何進行SQL注入測試
首先，找到帶有參數傳遞的URL頁面,如 搜尋頁面,登入頁面,送出評論頁面等等.
注1:對于未明顯辨別在URL中傳遞參數的,可以通過檢視HTML源代碼中的"FORM"标簽來辨識是否還有參數傳遞。在
和
的标簽中間的每一個參數傳遞都有可能被利用。
HTML代碼：
method="get">
id="search_q" value="" />
src="/media/images/site/search_btn.gif" />
class="fl">Gamefinder
注
2:當你找不到有輸入行為的頁面時,可以嘗試找一些帶有某些參數的特殊的URL,如HTTP://DOMAIN/INDEX.ASP?ID=10
其次，在URL參數或表單中加入某些特殊的SQL語句或SQL片斷,如在登入頁面的URL中輸入HTTP://DOMAIN
/INDEX.ASP?USERNAME=HI' OR 1=1--
注1：根據實際情況,SQL注入請求可以使用以下語句:
' or 1=1- -
" or 1=1- -
or 1=1- -
' or 'a'='a
" or "a"="a
') or ('a'='a 注2：為什麼是OR， 以及',――是特殊的字元呢？
例子：在登入時進行身份驗證時，通常使用如下語句來進行驗證：sql=select * from user
where username='username' and pwd='password'
如 輸入http://duck/index.asp?username=admin' or
1='1&pwd=11，SQL語句會變成以下：sql=select *
from user where username='admin' or 1='1' and
password='11'
'
與admin前面的'組成了一個查詢條件,即username='admin',接下來的語句将按下一個查詢條件來執行.
接 下來是OR查詢條件,OR是一個邏輯運
算符，在判斷多個條件的時候，隻要一個成立，則等式就成立，後面的AND就不再時行判斷了，也就是
說我們繞過了密碼驗證，我們隻用使用者名就可以登入.
如 輸入http://duck/index.asp?username=admin'--&pwd=11，SQL語
句會變成以下sql=select * from user where name='admin' --' and
pasword='11',
'與admin前面的'組成了一個查
詢條件,即username='admin',接下來的語句将按下一個查詢條件來執行
接下來是"--"查詢條件,“--”是忽略或注釋,上
述通過連接配接符注釋掉後面的密碼驗證(注:對ACCESS資料庫無 效).
最後,驗證是否能入侵成功，或是出錯的資訊是否包含關于資料庫伺服器的相關資訊，如果能，說明存在SQL安全漏洞。
試想,如果網站存在SQL注入的危險,對于有經驗的惡意使用者還可能猜出資料庫表和表結構,并對資料庫表進行增\删\改的操
作,這樣造成的後果是非常嚴重的。
三、如何預防SQL注入?從應用程式的角度來講,我們要做以下三項工作:
轉義敏感字元及字元串(SQL的敏感字元包括“exec”,”xp_”,”sp_”,”declare”,”Union”,”cmd”,”+”,”//”,”..”,”;”,”‘”,”--”,”%”,”0x”,”><=!-*/()|”,和”空格”).
屏蔽出錯資訊：阻止攻擊者知道攻擊的結果
在服務端正式處理之前送出資料的合法性(合法性檢查主要包括三
項:資料類型,資料長度,敏感字元的校驗)進行檢查等。最根本的解決手段,在确認客
戶端的輸入合法之前,服務端拒絕進行關鍵性的處理操作.從測試人員的角度來講,在程式開發前(即需求階段),我們就應該有意識的将安全性檢查應用到需求測試中,例如對一個表單需求進行檢查時,我們一般檢驗以下幾項安全性問題:
需求中應說明表單中某一FIELD的類型,長度,以及取值範圍(主要作用就是禁止輸入敏感字元)
需求中應說明如果超出表單規定的類型,長度,以及取值範圍的,應用程式應給出不包含任何代碼或資料庫資訊的錯誤提示.
當然在執行測試的過程中,我們也需求對上述兩項内容進行測試。