SQL注入攻擊的本質：讓客戶端傳遞過去的字符串變成SQL語句，而且能夠被執行。
每個程序員都必須肩負起防止SQL注入攻擊的責任。
說起防止SQL注入攻擊，感覺很鬱悶，這麼多年了大家一直在討論，也一直在爭論，可是到了現在似乎還是沒有定論。當不知道注入原理的時候會覺得很神奇， 怎麼就被注入了呢？會覺得很難預防。但是當知道了注入原理之後預防不就是很簡單的事情了嗎？
第一次聽說SQL注入攻擊的時候還是在2004年（好像得知的比較晚），那是還是在寫asp呢。在一次寫代碼的時候，有同事問我，你的這段代碼 防注入攻擊了嗎？什麼攻擊？這是什麼呀。
後來到網上各種找，終於弄明白了是怎麼攻擊進來的了。注入攻擊都是來自於客戶端，無論是表單提交、 URL傳值還是Cookie等，其實原理都是一樣的。到了服務器端可以分成三種情況：數字、日期時間、字符串。
一、數字。
如何注入？
假設我們要實現一個顯示新聞的頁面，我們可能會隨手寫下下面的代碼：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->string id = Request.QueryString["id"];
string sql = ”select * from news where ColID=” + id;
如果傳遞過來的 id是我們想像的 數字（比如168），那麼自然不會有什麼問題。但是如果傳遞過來的id是“168 delete from table ”的話，那麼sql的值就變成了“select * from table where ColID=168 delete from news”。對於SQL Server來說是支持一次提交多條SQL語句的，這個爲我們提供了方便之餘也爲SQL注入敞開了大門。顯然如果這條SQL語句被執行的話，那麼news 表裏的記錄就都沒有了。
那麼如何預防呢？很簡單，因爲ColID字段的類型是int的，那麼我們只需要驗證一下傳遞過來的id是不是整數就可以了。是整數就不存在注入； 如果不是那麼就有可能存在注入。即使不存在注入，把一個不是整數的id拼接進去也會造成執行錯誤。
所以說不管是不是爲了預防SQL注入，也都 應該驗證id是不是整數。
驗證方法嘛，可以用TryParse，可以用正則，也可以自己寫函數驗證。但是不建議用try異常的方式，因爲這個有效率問題。
這裏還有一個特殊情況，就是對於批量刪除這類的會傳遞過來多個數字，比如“1，2，3，10”，這個也需要驗證一下，萬一有人利用這個漏洞呢。 至於驗證方法也很簡單，自己寫個函數就ok了。
二、日期時間
這個和數字的情況是一樣的，驗證是不是日期時間即可。
三、字符串
最麻煩、爭議最大的就是這個了。
先看一下如何注入
比如我們先要按照新聞標題來進行查詢，可能寫的代碼：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->string key = txtTitle.Text;
string sql = ”select * from news where title like ’%” + key + ”%’”;
這個又是如何注入的呢？我想先問大家一個問題：如果key的值永遠都不會包含單引號，那麼會不會被注入進來？
那麼用了單引號又是如何注入的呢？假設key=” ‘ delete from news –” ，那麼sql的值就是“ select * from news where title like ‘%’ delete from news – ’ ”。
先用一 個單引號和前面的單引號組成一對封閉的單引號，這一對單引號內部（’%'）就作爲字符串處理，而外面的就被作爲SQL語句處理，而第二個單引號被 “–”給註釋掉了，這樣就保證了整個sql語句的正確性。
這是注入的一種方法。
那麼如何來防止呢？想想剛纔的問題，如果沒有單引號是不是就天下太平了呢？對於這種情況（前面的“數字”的情況不算），到目前爲止我是沒發現不 用單引號，還能夠注入進來的方法。也許是我孤陋寡聞吧，不知道各位高手是否知道對於這種情況，不用單引號還能注入進來的方法。
既然找到了罪魁禍首，那麼就好辦了，把單引號幹掉就ok了。key = key.Replace(“‘”, “””);這時候sql的值就是” select * from news where title like ‘%” delete from news –’”。
對於SQL 來說在一對單引號內部的兩個單引號表示一個字符串形式的單引號。這樣我們就把罪魁禍首改造成了字符串了。在一對單引號內的“–”也是普通的字符串而不代 表註釋。
罪魁禍首是單引號，想不明白爲什麼有許多人都去過濾 “delete、update”這一類的關鍵字，他們都是安善良民呀，他們是很冤枉的。當然了，如果前提是程序都已經寫好了，不能修改內部代碼，那就另當 別論了。至於“–”頂多算是幫兇，如果您不放心的話，把他處理了也行。
總結：數字、日期時間的，驗證類型；字符串的，處理好單引號。
另外爲了安全起見，不要用sa連接數據庫，xp_cmdshell這一類的有危險的擴展存儲過程也 應該處理一下（比如刪除）。
ps：添加修改數據的時候可以用參數化的SQL語句，但是目的不是防止注入，而是重用執行計劃。
還有就是js腳本的問題，這個還沒有仔細考慮，可以用html編碼的方式，也可以用替換的方式，還有ubb的漏洞等。