1、 SQL注入攻擊的本質:讓用戶端傳遞過去的字串變成SQL語句,而且能夠被執行。
2、 每個程式師都必須肩負起防止SQL注入攻擊的責任。
說起防止SQL注入攻擊,感覺很鬱悶,這麼多年了大家一直在討論,也一直在爭論,可是到了現在似乎還是沒有定論。當不知道注入原理的時候會覺得很神奇,怎麼就被注入了呢?會覺得很難預防。但是當知道了注入原理之後預防不就是很簡單的事情了嗎?
第一次聽說SQL注入攻擊的時候還是在2004年(好像得知的比較晚),那是還是在寫asp呢。在一次寫代碼的時候,有同事問我,你的這段代碼防注入攻擊了嗎?什麼攻擊?這是什麼呀。
後來到網上各種找,終於弄明白了是怎麼攻擊進來的了。注入攻擊都是來自于用戶端,無論是表單提交、URL傳值還是Cookie等,其實原理都是一樣的。到了伺服器端可以分成三種情況:數位、日期時間、字串。
一、數位。
如何注入?
假設我們要實現一個顯示新聞的頁面,我們可能會隨手寫下下面的代碼:



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了。
二、日期時間
這個和數位的情況是一樣的,驗證是不是日期時間即可。
三、字串

 

最麻煩、爭議最大的就是這個了。
先看一下如何注入
比如我們先要按照新聞標題來進行查詢,可能寫的代碼:

 

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的漏洞等。
創作者介紹
創作者 shadow 的頭像
shadow

資訊園

shadow 發表在 痞客邦 留言(0) 人氣()