A. 什麼是sql注入
SQL注入：利用現有應用程序，將(惡意)的SQL命令注入到後台資料庫引擎執行的能力，這是SQL注入的標准釋義。
隨著B/S模式被廣泛的應用，用這種模式編寫應用程序的程序員也越來越多，但由於開發人員的水平和經驗參差不齊，相當一部分的開發人員在編寫代碼的時候，沒有對用戶的輸入數據或者是頁面中所攜帶的信息（如Cookie）進行必要的合法性判斷，導致了攻擊者可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得一些他想得到的數據。
SQL注入利用的是正常的HTTP服務埠，表面上看來和正常的web訪問沒有區別，隱蔽性極強，不易被發現。
SQL注入攻擊過程分為五個步驟：
第一步：判斷Web環境是否可以SQL注入。如果URL僅是對網頁的訪問，不存在SQL注入問題，如：http://www.../162414739931.shtml就是普通的網頁訪問。只有對資料庫進行動態查詢的業務才可能存在SQL注入，如：http://www...../webhp?id＝39，其中?id＝39表示資料庫查詢變數，這種語句會在資料庫中執行，因此可能會給資料庫帶來威脅。
第二步：尋找SQL注入點。完成上一步的片斷後，就要尋找可利用的注入漏洞，通過輸入一些特殊語句，可以根據瀏覽器返回信息，判斷資料庫類型，從而構建資料庫查詢語句找到注入點。
第三步：猜解用戶名和密碼。資料庫中存放的表名、欄位名都是有規律可言的。通過構建特殊資料庫語句在資料庫中依次查找表名、欄位名、用戶名和密碼的長度，以及內容。這個猜測過程可以通過網上大量注入工具快速實現，並藉助破解網站輕易破譯用戶密碼。
第四步：尋找WEB管理後台入口。通常WEB後台管理的界面不面向普通用戶
開放，要尋找到後台的登陸路徑，可以利用掃描工具快速搜索到可能的登陸地址，依次進行嘗試，就可以試出管理台的入口地址。
第五步：入侵和破壞。成功登陸後台管理後，接下來就可以任意進行破壞行為，如篡改網頁、上傳木馬、修改、泄漏用戶信息等，並進一步入侵資料庫伺服器。
SQL注入攻擊的特點:
變種極多，有經驗的攻擊者會手動調整攻擊參數，致使攻擊數據的變種是不可枚舉的，這導致傳統的特徵匹配檢測方法僅能識別相當少的攻擊，難以防範。
攻擊過程簡單，目前互聯網上流行眾多的SQL注入攻擊工具，攻擊者藉助這些工具可很快對目標WEB系統實施攻擊和破壞。
危害大，由於WEB編程語言自身的缺陷以及具有安全編程能力的開發人員少之又少，大多數WEB業務系統均具有被SQL注入攻擊的可能。而攻擊者一旦攻擊成功，可以對控制整個WEB業務系統，對數據做任意的修改，破壞力達到及至。
SQL注入的危害和現狀
SQL注入的主要危害包括：
未經授權狀況下操作資料庫中的數據
惡意篡改網頁內容
私自添加系統帳號或者是資料庫使用者帳號
網頁掛木馬
如何防止SQL參數：
1，檢查上傳的數據，並過濾
2. 禁止拼接SQL字元串
3.使用SQL參數化處理
4．載入防入侵等硬體設施
B. SQL注入求指點
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。
SQL注入大致方法：
1、猜表名And
(Select
count(*)
from
表名)<>0，猜列名And
(Select
count(列名)
from
表名)<>0，獲得資料庫連接用戶名：and
user>0
2、後台身份驗證繞過漏洞，'or'='or'後台繞過漏洞，利用的就是AND和OR的運算規則，從而造成後台腳本邏輯性錯誤。
防止SQL注入：
1.對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky,網站平台就有億思網站安全平台檢測工具。
C. 什麼是sql注入攻擊
請參考SQL 注入天書～
所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令，比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是sql注入就發生了。
D. 求教誰給講講SQL注入攻擊的步驟
第一步：SQL注入點探測。探測SQL注入點是關鍵的第一步，通過適當的分析應用程序，可以判斷什麼地方存在SQL注入點。通常只要帶有輸入提交的動態網頁，並且動態網頁訪問資料庫，就可能存在SQL注入漏洞。如果程序員信息安全意識不強，採用動態構造SQL語句訪問資料庫，並且對用戶輸入未進行有效驗證，則存在SQL注入漏洞的可能性很大。一般通過頁面的報錯信息來確定是否存在SQL注入漏洞。
第二步：收集後台資料庫信息。不同資料庫的注入方法、函數都不盡相同，因此在注入之前，我們先要判斷一下資料庫的類型。判斷資料庫類型的方法有很多，可以輸入特殊字元，如單引號，讓程序返回錯誤信息，我們根據錯誤信息提示進行判斷，還可以使用特定函數來判斷。
第三步：猜解用戶名和密碼。資料庫中的表和欄位命名一般都是有規律的，通過構造特殊的SQL語句在資料庫中依次猜解出表名、欄位名、欄位數、用戶名和密碼。
第四步：查找Web後台管理入口。Web後台管理通常不對普通用戶開放，要找到後台管理的登錄網址，可以利用Web目錄掃描工具快速搜索到可能的登錄地址，然後逐一嘗試，便可以找到後台管理平台的登錄網址。
第五步：入侵和破壞。一般後台管理具有較高許可權和較多的功能，使用前面已破譯的用戶名、密碼成功登錄後台管理平台後，就可以任意進行破壞，比如上傳木馬、篡改網頁、修改和竊取信息等，還可以進一步提權，入侵Web伺服器和資料庫伺服器。
E. 什麼是sql注入，怎麼防止sql注入
原理
SQL注入攻擊指的是通過構建特殊的輸入作為參數傳入Web應用程序，而這些輸入大都是SQL語法里的一些組合，通過執行SQL語句進而執行攻擊者所要的操作，其主要原因是程序沒有細致地過濾用戶輸入的數據，致使非法數據侵入系統。
根據相關技術原理，SQL注入可以分為平台層注入和代碼層注入。前者由不安全的資料庫配置或資料庫平台的漏洞所致；後者主要是由於程序員對輸入未進行細致地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面：①不當的類型處理；②不安全的資料庫配置；③不合理的查詢集處理；④不當的錯誤處理；⑤轉義字元處理不合適；⑥多個提交處理不當。
攻擊
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。相關的SQL注入可以通過測試工具pangolin進行。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是sql注入就發生了。
防護
歸納一下，主要有以下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和
雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky，網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS攻擊等。
F. 資料庫操作中哪種情況會出現SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令
什麼時候最易受到sql注入攻擊
當應用程序使用輸入內容來構造動態sql語句以訪問資料庫時，會發生sql注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生sql注入。sql注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。相關的SQL注入可以通過測試工具pangolin進行。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造動態sql命令，或者作為存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是sql注入就發生了。
SQL注入的手法相當靈活，在注入的時候會碰到很多意外的情況。能不能根據具體情況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據，是高手與「菜鳥」的根本區別。
注入大致方法
方法1
先猜表名 And (Select count(*) from 表名)<>0 猜列名 And (Select count（列名） from 表名）<>0 或者也可以這樣 and exists (select * from 表名） and exists (select 列名 from 表名） 返回正確的，那麼寫的表名或列名就是正確 這里要注意的是，exists這個不能應用於猜內容上，例如and exists (select len(user) from admin)>3 這樣是不行的 現在很多人都是喜歡查詢裡面的內容，一旦iis沒有關閉錯誤提示的，那麼就可以利用報錯方法輕松獲得庫裡面的內容 獲得資料庫連接用戶名：；and user>0 這個是小竹提出來的，我這里引用《SQL注入天書》裡面的一段話來講解：
"重點在and user>0，我們知道，user是SQLServer的一個內置變數，它的值是當前連接的用戶名，類型為nvarchar。拿一個 nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，當然，轉的過程中肯定會出錯，SQLServer的出錯提示是：將nvarchar轉換int異常，XXXX不能轉換成int" 看到這里大家明白了吧，報錯的原理就是利用SQLserver內置的系統表進行轉換查詢，轉換過程會出錯，然後就會顯示出在網頁上，另外還有類似的and 1=(selet top 1 user from admin），這種語句也是可以爆出來的。；and db_name()>0 則是暴資料庫名。 一旦關閉了IIS報錯，那麼還可以用union（聯合查詢）來查內容，主要語句就是 Order by 10 And 1=2 union select 1,2,3,4,5,6,7,8,9,10 from admin And 1=2 union select 1,2,3,user,5,passwd,7,8,9,10 from admin 上面的order by 10主要就是查欄位數目，admin就是表名，可以自己猜，user,passwd是列名 反正就是返回正確即對，返回異常即錯 另外還有十分常用的ascll碼拆半法 先要知道指定列名，例如user里的內容的長度 and (select len(user) from admin)=2 就是查詢長度為不為2位，返回錯誤的增加或減少數字，一般這個數字不會太大，太大的就要放棄了，猜也多餘 後面的邏輯符號可以根據不同要求更改的， >；大於 <；小於 =就是等於咯，更新語句的話，=也可以表示傳遞符號 <>；就是不等 知道了長度後就可以開始猜解了 And (Select top 1 asc(mid(user,n,1)) from admin)>100 n就是猜解的表名的第幾位，最後的長度數字就是剛才猜解出來的列名長度了，And (Select top 1 asc(mid(user,1,1)) from admin)>100 就是猜解user里內容的第一位的ASCLL字元是不是大於100 正確的話，那麼表示USER第一個字元的ASCLL碼大於100，那麼就猜>120，返回錯誤就是介於100－120之間，然後再一步一步的縮少，最終得到正確字元XXX，然後用ASCLL轉換器吧這個轉換成普通字元就可以了 然後就是第二位 And (Select top 1 asc(mid(user,2,1)) from admin)>100 一直猜下去 加在url後面，列名表名還是先猜解，返回正確的代表帳號的ascll碼大於100，那麼就再向前猜，指導報錯，把猜出來的ascll碼拿去ascll轉換器轉換就可以了，中文是負數，加上asb取絕對值 And (Select top 1 asb(asc(mid(user,n,1))) from admin)>15320 得到之後就記得在數字前加-號，不然ASCLL轉換器轉換不來的，中文在ASCLL碼里是-23423這樣的，所以猜起來挺麻煩 這個猜解速度比較慢，但是效果最好，最具有廣泛性
方法2
後台身份驗證繞過漏洞 驗證繞過漏洞就是'or'='or'後台繞過漏洞，利用的就是AND和OR的運算規則，從而造成後台腳本邏輯性錯誤 例如管理員的賬號密碼都是admin，那麼再比如後台的資料庫查詢語句是 user=request("user") passwd=request("passwd") sql='select admin from adminbate where user='&'''&user&'''&' and passwd='&'''&passwd&''' 那麼我使用'or 'a'='a來做用戶名密碼的話，那麼查詢就變成了 select admin from adminbate where user=''or 'a'='a' and passwd=''or 'a'='a' 這樣的話，根據運算規則，這里一共有4個查詢語句，那麼查詢結果就是 假or真and假or真，先算and 再算or，最終結果為真，這樣就可以進到後台了 這種漏洞存在必須要有2個條件，第一個：在後台驗證代碼上，賬號密碼的查詢是要同一條查詢語句，也就是類似 sql="select * from admin where username='"&username&'&"passwd='"&passwd&' 如果一旦賬號密碼是分開查詢的，先查帳號，再查密碼，這樣的話就沒有辦法了。 第二就是要看密碼加不加密，一旦被MD5加密或者其他加密方式加密的，那就要看第一種條件有沒有可以，沒有達到第一種條件的話，那就沒有戲了
摘自：http://ke..com/view/3896.htm
G. 試解釋 SQL 注入攻擊的原理，以及對資料庫可能產生的不利影響。
SQL注入就是攻擊者通過正常的WEB頁面,把自己SQL代碼傳入到應用程序中,從而通過執行非程序員預期的SQL代碼,達到竊取數據或破壞的目的。
當應用程序使用輸入內容來構造動態SQL語句以訪問資料庫時，會發生SQL注入攻擊。如果代碼使用存儲過程，而這些存儲過程作為包含未篩選的用戶輸入的字元串來傳遞，也會發生SQL注入。SQL注入可能導致攻擊者使用應用程序登陸在資料庫中執行命令。如果應用程序使用特權過高的帳戶連接到資料庫，這種問題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造（或者影響）動態SQL命令，或者作為存儲過程的輸入參數，這些表單特別容易受到SQL注入的攻擊。而許多網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變數處理不當，使應用程序存在安全隱患。這樣，用戶就可以提交一段資料庫查詢的代碼，根據程序返回的結果，獲得一些敏感的信息或者控制整個伺服器，於是SQL注入就發生了。
一般SQL注入
在Web 應用程序的登錄驗證程序中,一般有用戶名(username) 和密碼(password) 兩個參數,程序會通過用戶所提交輸入的用戶名和密碼來執行授權操作。我們有很多人喜歡將SQL語句拼接起來。例如：
Select * from users where username =』 txtusername.Text 』 and password =』 txtpassword.Text 』
其原理是通過查找users 表中的用戶名(username) 和密碼(password) 的結果來進行授權訪問, 在txtusername.Text為mysql，txtpassword.Text為mary，那麼SQL查詢語句就為：
Select * from users where username =』 mysql 』 and password =』 mary 』
如果分別給txtusername.Text 和txtpassword.Text賦值』 or 『1』 = 『1』 --和abc。那麼,SQL 腳本解釋器中的上述語句就會變為:
Select * from users where username =』』or 『1』 = 『1』 -- and password =』abc』
該語句中進行了兩個條件判斷,只要一個條件成立,就會執行成功。而'1'='1'在邏輯判斷上是恆成立的,後面的"--" 表示注釋,即後面所有的語句為注釋語句這樣我們就成功登錄。即SQL注入成功.
如果我們給txtusername.Text賦值為:』;drop table users--即:
Select * from users where username =』』;drop table users-- and password =』abc』
整個用戶表就沒有了，當然這里要猜出數據表名稱。想想是多麼可怕的事情。
好我想大家在這里已經大致明白了一般SQL注入了，試想下您的登錄程序會不會出現我上述的情況。
防範SQL注入
那麼現在大家都在思考怎麼防範SQL注入了這里給出一點個人的建議
1.限制錯誤信息的輸出
這個方法不能阻止SQL注入，但是會加大SQL注入的難度，不會讓注入者輕易得到一些信息，讓他們任意破壞資料庫。SQL Server有一些系統變數，如果我們沒有限制錯誤信息的輸出，那麼注入著可以直接從出錯信息獲取，例如（假定這里用的string即字元類型並可以發生SQL注入）：http://www.xxx.com/showdetail.aspx?id=49 and user>0 這句語句很簡單，但卻包含了SQL Server特有注入方法的精髓，。首先看看它的含義：首先，前面的語句是正常的，重點在and user>0，我們知道，user是SQL Server的一個內置變數，它的值是當前連接的用戶名，類型為nvarchar。拿一個nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，當然，轉的過程中肯定會出錯，SQL Server的出錯提示是：將nvarchar值 」abc」 轉換數據類型為 int 的列時發生語法錯誤，呵呵，abc正是變數user的值，這樣，注入著就拿到了資料庫的用戶名。
眾所周知，SQL Server的用戶sa是個等同Adminstrators許可權的角色，拿到了sa許可權，幾乎肯定可以拿到主機的Administrator了。上面的方法可以很方便的測試出是否是用sa登錄，要注意的是：如果是sa登錄，提示是將」dbo」轉換成int的列發生錯誤，而不是」sa」。
當然注入者還可以輸入不同的信息來得到他們想要的信息 ，上面只是其中一個例子，所以我們要限制錯誤信息的輸出，從而保護我們的資料庫數據，這里我給出.NET限制錯誤信息的方法：
在Web.Config文件中設置
<customErrors mode="On" defaultRedirect="error.aspx">
</customErrors>
這樣當發生錯誤時候就不會講信息泄露給外人。
2.限制訪問資料庫帳號的許可權
對於資料庫的任何操作都是以某種特定身份和相應許可權來完成的,SQL語句執行前,在資料庫伺服器端都有一個用戶許可權驗證的過程,只有具備相應許可權的帳號才可能執行相應許可權內的SQL語句。因此,限制資料庫帳號許可權,實際上就阻斷了某些SQL語句執行的可能。不過,這種方法並不能根本解決SQL注入問題,因為連接資料庫的帳號幾乎總是比其他單個用戶帳號擁有更多的許可權。通過限制貼帳號許可權,可以防止刪除表的攻擊,但不能阻止攻擊者偷看別人的信息。
3.參數化使用命令
參數化命令是在SQL文本中使用佔位符的命令。佔位符表示需要動態替換的數據,它們通過Command對象Parameters集合來傳送。能導致攻擊的SQL代碼可以寫成:
Select * from employee where userID=@userID;
如果用戶輸入: 09105022』OR 『1』=』1,將得不到何記錄,因為沒有一個用戶ID與文本框中輸入的』 09105022』OR 『1』=』1』相等。參數化命令的語法隨提供程序的不同略有差異。對於SQL SERVER提供程序,參數化命令使用命名的佔位符(具有唯一的名字),而對於OLE DB提供程序,每個硬編碼的值被問號代替。使用OLE DB提供程序時,需要保證參數的順序和它們出現在SQL字元串中的位置一致。SQL SERVER提供程序沒有這樣的需求,因為它們用名字和佔位符匹配。
4.調用存儲過程
存儲過程是存儲在資料庫伺服器上的一系列SQL代碼,存儲過程與函數相似,有良好的邏輯封裝結構,可以接收和返回數據。使用存儲過程可以使代碼更易於維護,因為對存儲過程的更改不會導致應用程序的重新編譯,使用存儲過程還可以節省帶寬,提高應用程序性能。因為存儲過程是存儲在資料庫服務端的獨立的封裝體,調用存儲過程可以保證應用程序只執行存儲過程中的固定代碼,從而杜絕SQL語句注入的可能。結合上述所講的參數化命令,可以實現SQL代碼可以實現的任何功能,並進一步提高應用程序的安全等級。
5.限制輸入長度
如果在Web頁面上使用文本框收集用戶輸入的數據,使用文本框的MaxLength屬性來限制用戶輸入過長的字元也是一個很好的方法,因為用戶的輸入不夠長,也就減少了貼入大量腳本的可能性。程序員可以針對需要收集的數據類型作出一個相應的限制策略。
6.URL重寫技術
我們利用URL重寫技術過濾一些SQL注入字元，從而達到防禦SQL注入。因為許多SQL注入是從URL輸入發生的。
7.傳遞參數盡量不是字元
假設我們顯示一篇新聞的頁面，從URL傳遞參數中獲得newid我們可能會隨手寫下下面的代碼：
string newsid = Request.QueryString["newsid"];
string newssql = "select * from news where newsid=" + newsid;
如果傳遞過來的參數是數字字元就沒有問題。但是如果傳遞過來的newsid是「1 delete from table 」的話，那麼sql的值就變成了「select * from table where newsid=1 delete from news」。發生注入成功。但是這里改為
int newsid=int.Parse(Request.QueryString["newsid"].ToString());
string newssql = "select * from news where newsid=" + newsid.Tostring();
這里如果還是上面"1 delete from table "會發生錯誤，因為在轉換時候出現了錯誤
從上面的一個小例子，我們得出在傳遞參數時候盡量不要用字元，免得被注入。
最後是我想擴展下利用URL重寫技術來過濾一些SQL注入字元，首先這里有一篇關於URL重寫的文章，我的基本思想是可以利用它，屏蔽一些危險的SQL注入字元串，這些字元串我們可以人為的設定，畢竟我們還是根據特定的環境設定我們防禦措施。首先我們在MoleRewriter類中的Rewrite函數得到絕對的URL判斷其中是否有危險字元，如果有我們就將它鏈接到一個提示用戶您輸入危險的URL地址。如果不是我們繼續判斷是否觸發了其他的URL重寫的規則，觸發了就重寫。這樣就大致上能在URL上防禦危險字元。
代碼
<configSections>
<section name="RewriterConfig" type="URLRewriter.Config., URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default_sql_error.aspx</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default2.aspx</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
<httpMoles>
<add type="URLRewriter.MoleRewriter, URLRewriter" name="MoleRewriter" />
</httpMoles>
上面是要在web.config配置文件加上的內容，這里我加上了兩個重寫規則，第一個規則是專門針對滿足這個正則表達式的頁面URL查看是否有危險字元，有危險字元就會發送到Default_sql_error.aspx頁面，來示警。這里我假定會發生危險字元注入的頁面時以"d"字元開頭並加上數字的頁面（這里我們可以根據實際情況自己定義，看哪些頁面URL容易發生我們就制定這些頁面的正則表達式），第二個是一般URL重寫。因為這里我採用的是HTTP模塊執行URL重寫，所以加上<httpMoles></httpMoles>這一塊。
第二步就是要在重寫Rewrite函數了
代碼
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 獲得配置規則
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;
//獲得絕對的URL
Uri url = app.Request.Url;
// 判斷url 中是否含有SQL 注入攻擊敏感的字元或字元串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;
//這里我們根據實際情況隨便編寫，我這里這是隨便列舉了幾個
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";
string[] split = words.Split(',');
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 創建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的規則,進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
}
else
{
// 遍歷除rules[0 ]以外的其他URL 重寫規則
for (int i = 1; i < rules.Count; i++)
{
// 獲得要查找的模式,並且解析URL (轉換為相應的目錄)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 創建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的規則
if (re.IsMatch(requestedPath))
{
// 找到了匹配的規則, 進行必要的替換
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重寫URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循環
}
}
}
}
那麼下一步就是檢驗例子了
首先我們輸入http://localhost:4563/web/Default.aspx?id=1;--
這樣http://localhost:4563/web/Default.aspx?id=1;-- 沒有改變，就會顯示Default_sql_error.aspx里內容「您輸入了危險字元」。
再輸入http://localhost:4563/web/D11.aspx就會顯示 Default2.aspx內容，因為這里觸發了第二個重寫規則
H. 動態SQL的使用
在介紹動態SQL前我們先看看什麼是靜態SQL
靜態SQL
靜態 SQL 語句一般用於嵌入式 SQL 應用中，在程序運行前，SQL 語句必須是確定的，例如 SQL 語句中涉及的列名和表名必須是存在的。靜態 SQL 語句的編譯是在應用程序運行前進行的，編譯的結果會存儲在資料庫內部。而後程序運行時，資料庫將直接執行編譯好的 SQL 語句，降低運行時的開銷。
動態SQL
動態 SQL 語句是在應用程序運行時被編譯和執行的，例如，使用 DB2 的互動式工具 CLP 訪問資料庫時，用戶輸入的 SQL 語句是不確定的，因此 SQL 語句只能被動態地編譯。動態 SQL 的應用較多，常見的 CLI 和 JDBC 應用程序都使用動態 SQL。
動態SQL作用
動態SQL執行方法
使用EXEC(EXECUTE的縮寫)命令和使用SP_EXECUTERSQL。
EXEC命令執行
語法
註：EXECUTE 命令有兩個用途，一個是用來執行存儲過程，另一個是執行動態SQL
不帶參數示例
在變數@SQL中保存了一個字元串，該字元串中包含一條查詢語句，再用EXEC調用保存在變數中的批處理代碼，我們可以這樣寫SQL：
EXEC ('SELECT * FROM Customers')
結果如下：
與我們直接執行SELECT * FROM Customers一樣。
帶參數示例
還是上面的示例，我們換一種寫法
DECLARE @SQL AS VARCHAR(100);
DECLARE @Column AS VARCHAR(20);
SET @Column = '姓名'
SET @SQL = 'SELECT ' + @Column + ' FROM Customers'
EXEC (@SQL)
結果如下：
SP_EXECUTERSQL執行
語法
注意：SP_EXECUTERSQL是繼EXEC後另一種執行動態SQL的方法。使用這個存儲過程更加安全和靈活，因為它支持輸入和輸出參數。注意的是，與EXEC不同的是,SP_EXECUTERSQL只支持使用Unicode字元串作為其輸入的批處理代碼。
示例
構造了一個對Customers表進行查詢的批處理代碼，在其查詢過濾條件中使用一個輸入參數@CusID
DECLARE @SQL AS NVARCHAR(100);
SET @SQL=N'SELECT * FROM Customers
WHERE 客戶ID=@CusID;'
EXEC SP_EXECUTESQL
@STMT=@SQL,
@PARMS=N'@CusID AS INT',
@CusID=1;
結果如下：
代碼中將輸入參數取值指定為1，但即使採用不同的值在運行這段代碼，代碼字元串仍然保存相同。這樣就可以增加重用以前緩存過的執行計劃的機會