最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
當(dāng)前位置: 首頁 - 科技 - 知識百科 - 正文

asp.net 預(yù)防SQL注入攻擊之我見

來源:懂視網(wǎng) 責(zé)編:小采 時(shí)間:2020-11-27 22:43:51
文檔

asp.net 預(yù)防SQL注入攻擊之我見

asp.net 預(yù)防SQL注入攻擊之我見:1、 SQL注入攻擊的本質(zhì):讓客戶端傳遞過去的字符串變成SQL語句,而且能夠被執(zhí)行。 2、 每個(gè)程序員都必須肩負(fù)起防止SQL注入攻擊的責(zé)任。 說起防止SQL注入攻擊,感覺很郁悶,這么多年了大家一直在討論,也一直在爭論,可是到了現(xiàn)在似乎還是沒有定論。當(dāng)不知道
推薦度:
導(dǎo)讀asp.net 預(yù)防SQL注入攻擊之我見:1、 SQL注入攻擊的本質(zhì):讓客戶端傳遞過去的字符串變成SQL語句,而且能夠被執(zhí)行。 2、 每個(gè)程序員都必須肩負(fù)起防止SQL注入攻擊的責(zé)任。 說起防止SQL注入攻擊,感覺很郁悶,這么多年了大家一直在討論,也一直在爭論,可是到了現(xiàn)在似乎還是沒有定論。當(dāng)不知道

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

string id = Request.QueryString["id"];
string sql = "select * from news where ColID=" + id;

  如果傳遞過來的 id是我們想像的 數(shù)字(比如168),那么自然不會有什么問題。但是如果傳遞過來的id是“168 delete from table ”的話,那么sql的值就變成了“select * from table where ColID=168 delete from news”。對于SQL Server來說是支持一次提交多條SQL語句的,這個(gè)為我們提供了方便之余也為SQL注入敞開了大門。顯然如果這條SQL語句被執(zhí)行的話,那么news表里的記錄就都沒有了。
 那么如何預(yù)防呢?很簡單,因?yàn)镃olID字段的類型是int的,那么我們只需要驗(yàn)證一下傳遞過來的id是不是整數(shù)就可以了。是整數(shù)就不存在注入;如果不是那么就有可能存在注入。即使不存在注入,把一個(gè)不是整數(shù)的id拼接進(jìn)去也會造成執(zhí)行錯(cuò)誤。
  所以說不管是不是為了預(yù)防SQL注入,也都應(yīng)該驗(yàn)證id是不是整數(shù)?! ?
  驗(yàn)證方法嘛,可以用TryParse,可以用正則,也可以自己寫函數(shù)驗(yàn)證。但是不建議用try異常的方式,因?yàn)檫@個(gè)有效率問題。
  這里還有一個(gè)特殊情況,就是對于批量刪除這類的會傳遞過來多個(gè)數(shù)字,比如“1,2,3,10”,這個(gè)也需要驗(yàn)證一下,萬一有人利用這個(gè)漏洞呢。至于驗(yàn)證方法也很簡單,自己寫個(gè)函數(shù)就ok了。
二、日期時(shí)間
  這個(gè)和數(shù)字的情況是一樣的,驗(yàn)證是不是日期時(shí)間即可。
三、字符串
  最麻煩、爭議最大的就是這個(gè)了。
  先看一下如何注入
  比如我們先要按照新聞標(biāo)題來進(jìn)行查詢,可能寫的代碼:
代碼如下:

string key = txtTitle.Text;
string sql = "select * from news where title like '%" + key + "%'";

  這個(gè)又是如何注入的呢?我想先問大家一個(gè)問題:如果key的值永遠(yuǎn)都不會包含單引號,那么會不會被注入進(jìn)來?
  那么用了單引號又是如何注入的呢?假設(shè)key=" ' delete from news --" ,那么sql的值就是“ select * from news where title like '%' delete from news -- ' ”。
  先用一個(gè)單引號和前面的單引號組成一對封閉的單引號,這一對單引號內(nèi)部('%')就作為字符串處理,而外面的就被作為SQL語句處理,而第二個(gè)單引號被 “--”給注釋掉了,這樣就保證了整個(gè)sql語句的正確性。
  這是注入的一種方法。
  那么如何來防止呢?想想剛才的問題,如果沒有單引號是不是就天下太平了呢?對于這種情況(前面的“數(shù)字”的情況不算),到目前為止我是沒發(fā)現(xiàn)不用單引號,還能夠注入進(jìn)來的方法。也許是我孤陋寡聞吧,不知道各位高手是否知道對于這種情況,不用單引號還能注入進(jìn)來的方法。
  既然找到了罪魁禍?zhǔn)?,那么就好辦了,把單引號干掉就ok了。key = key.Replace("'", "''");這時(shí)候sql的值就是” select * from news where title like '%'' delete from news --'”。
  對于SQL 來說在一對單引號內(nèi)部的兩個(gè)單引號表示一個(gè)字符串形式的單引號。這樣我們就把罪魁禍?zhǔn)赘脑斐闪俗址?。在一對單引號?nèi)的“--”也是普通的字符串而不代表注釋。
  罪魁禍?zhǔn)资菃我?,想不明白為什么有許多人都去過濾 “delete、update”這一類的關(guān)鍵字,他們都是安善良民呀,他們是很冤枉的。當(dāng)然了,如果前提是程序都已經(jīng)寫好了,不能修改內(nèi)部代碼,那就另當(dāng)別論了。至于“--”頂多算是幫兇,如果您不放心的話,把他處理了也行。
  總結(jié):數(shù)字、日期時(shí)間的,驗(yàn)證類型;字符串的,處理好單引號。
  另外為了安全起見,不要用sa連接數(shù)據(jù)庫,xp_cmdshell這一類的有危險(xiǎn)的擴(kuò)展存儲過程也應(yīng)該處理一下(比如刪除)。
ps:添加修改數(shù)據(jù)的時(shí)候可以用參數(shù)化的SQL語句,但是目的不是防止注入,而是重用執(zhí)行計(jì)劃。
還有就是js腳本的問題,這個(gè)還沒有仔細(xì)考慮,可以用html編碼的方式,也可以用替換的方式,還有ubb的漏洞等。

聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文檔

asp.net 預(yù)防SQL注入攻擊之我見

asp.net 預(yù)防SQL注入攻擊之我見:1、 SQL注入攻擊的本質(zhì):讓客戶端傳遞過去的字符串變成SQL語句,而且能夠被執(zhí)行。 2、 每個(gè)程序員都必須肩負(fù)起防止SQL注入攻擊的責(zé)任。 說起防止SQL注入攻擊,感覺很郁悶,這么多年了大家一直在討論,也一直在爭論,可是到了現(xiàn)在似乎還是沒有定論。當(dāng)不知道
推薦度:
標(biāo)簽: 防止 sql 攻擊
  • 熱門焦點(diǎn)

最新推薦

猜你喜歡

熱門推薦

專題
Top