防止sql注入性攻擊

1、關(guān)于防止sql注入的幾種手段 其實特別不愿意說sql注入的問題，因為這的確是 個老掉牙的問題了，但是仍然還有不少人在這方面自以為安全性做得很到位，或者說萬事只 要存儲過程就可以防止注入，即全都參數(shù)化，這樣對于某些復(fù)雜邏輯來說，sql存儲過程寫法太過于冗長，不如在 C#拼湊sql，也有很多人鄙視拼湊 sql的人，我覺得，看待 sql注入這 個問題，應(yīng)該是從本質(zhì)上來杜絕注入，而不是想當(dāng)然的依靠存儲過程，拒絕拼湊sql。我說一下我自己的經(jīng)驗吧一存儲過程參數(shù)化能解決絕大部分的注入問題。存儲過程之所以能夠解決絕大部分的注入問題，是因為mssql的機制，它認(rèn)為你的是參數(shù)就是參數(shù)不能夠解析為可執(zhí)行的sql。

2、但是這僅僅能解決絕大部分問題二當(dāng)需要在proc里面動態(tài)拼湊 sql，使用類似 exec，sp_executesql的時候，一定要使用后者，雖然兩者都是傳遞一個字符串，這個字符串作為sql語句執(zhí)行，但是后者提供為sql語句提供參數(shù)的功能，使得被執(zhí)行的sql語句參數(shù)化，而防止注入，前者如果使用傳入的參數(shù)來拼湊sql，則參數(shù)就會間接轉(zhuǎn)換成sql語句而導(dǎo)致注入。第二條或許應(yīng)該再補充一下，在mysql里，也有類似的執(zhí)行動態(tài)語句的，就是PREPARE+execute，這個的使用和 mssql里的sp_executesql功效相同，也能夠帶參數(shù)，防 止動態(tài)sql語句注入。在很多應(yīng)用場景里面，用戶最煩的就是分

3、頁的存儲過程寫法，所以，很多人就發(fā)明了通用的存儲過程分頁，可以通過site:通用存儲過程分頁在gg里搜索，居然有32000條收錄，先不說別的，看看排名前三位的的吧，1 ngyuli/archive/2009/01/13/1375196.html2 ng/archive/2005/09/02/228573.html3 nt/archive/2007/10/17/927825.html都是有注入漏洞的，隨便拿一個來試試注入，排名第一的， sql語句如下：0E Code這個是轉(zhuǎn)自鄒健大哥的，鄒健想必大家都認(rèn)識，讓我們來試一下他的通用存儲過程：exec sp_PageView 'article

4、','articleid',1,10,'subject,articleid',' articleid desc;select 1 as ''ok''',”，null看看返回什么吧:H結(jié)果1匕消息1articled1036262_在你沒成功前，你一定要堅持1036253今年牛市牛氣指數(shù)是多少？1036244謐州人敢想，溫州人更敢干103E235金融危機為民退國進(jìn)提供了機遇103622£物流電孑商務(wù)鳳起云涌.江湖決戰(zhàn)近在明年103E211Erw肝厠話耶波帝卡服怖總經(jīng)理吳詩梅103E18e創(chuàng)業(yè)的年齡10

5、36141ii i;注入成功!那這個到底怎么回事呢？ ？鄒健大哥的通用存儲過程都存在漏洞嗎？到底什么樣的寫法才不會被注入呢？太恐怖了上回說到鄒健大哥的存儲過程有漏洞，有人又提出這個很多都是程序員加上去的，壓根就不可能注入，的確，有很多拼湊sql的時候是程序里面加上去的，不是來自外界的直接”輸入。我上次的演示例子是基于的最后的排序，那如果要是在where條件里面呢？能保證100%都不是來自外界的輸入嗎？另外，軟件的分層開發(fā)，很多程序員的水平參差不齊， 能保證where條件都能100%保證過濾了外界的邪惡輸入嗎？還有，能保證過濾 100%能抵 擋黑客的攻擊嗎？這樣，我們再來看看園子里的人是如何防止

6、注入攻擊的，在gg搜索框輸入：site:防止 sql 注入2750 條記錄，第一篇是 文中只講了原則，沒有實施手段。提到的asp .net安全缺陷解決，在客戶端使用服務(wù)器驗證控件驗證，這個是絕對不可靠的，客戶端驗證是為的用戶體驗，黑客是不會在瀏覽器框里輸 入的。所有的驗證都必須要在服務(wù)器端再次驗證。排名第二位的是 , kill 朋友的，有具體的實施手段，防止sql注入的策略，一眼看去那個過濾，就知道有個地方?jīng)]有注意到，xp_cmdshell命令沒有過濾。肯定是有漏洞，當(dāng)然你可以保證你的系統(tǒng)里面擴(kuò)展存 儲過程是默認(rèn)關(guān)閉的，但是你不能保證其他閱讀了你文章的用戶基于某些原因開啟了擴(kuò)展存 儲過程。廢話

7、一下，強烈建議不要開啟擴(kuò)展存儲過程，如果要使用，看clr proc能不能滿足你的需求，不過開啟clr也是需要數(shù)據(jù)庫付出一定的代價的，數(shù)據(jù)庫不是很繁忙，可以開啟。排名第三位的是轉(zhuǎn)載自csdn的， ng/archive/2008/04/26/1172407.html也是基于的過濾。基于過濾的方法不是不行，不是達(dá)不到效果，而是基于過濾你不能保證你過濾完所有的 危險，如果你認(rèn)為你過濾完所有的危險，你覺得用戶會很方便嗎？就像我現(xiàn)在寫的文章一樣，如果博客園使用過濾，那我這篇文章能被發(fā)表嗎？所以基于過濾貌似是行不通的，但是有些 時候如果全都是參數(shù)化，存儲過程又太過于復(fù)雜，那些不經(jīng)常寫存儲過程的程序員很是頭疼

8、，怎么辦呢？總結(jié)我自己的開發(fā)經(jīng)驗來說，沒有任何絕對的，只有結(jié)合具體情況具體考慮。1檢查，類型檢查，如果是 int 定要tryparse,如果是有限的幾個值，一定要枚舉匹配。如 果是日期一定要轉(zhuǎn)成日期轉(zhuǎn)入數(shù)據(jù)層。2長度，長度是個非常重要的因素，比如登錄，如果用戶名是嚴(yán)格限死的10個字符以內(nèi)就10個字符以內(nèi)，用戶名中間沒有空格就檢查不能有空格，但是這個長度因素是需要嚴(yán)格控制的，不能把長度放開到10個字符以上，因為"truncate table s"和這個"drop table s",長度需要跟具體需求具體確定，不能全部一刀切。如果有哪位可以在10個字符以內(nèi)注

9、入成功的，還請告之，我趕緊改我的程序了，呵呵。3過濾檢查，如果壓根不可能出現(xiàn)xp_的地方一定要過濾，至于其他的， delete,drop，很多地方都不能確保如果前兩個檢查不能排除危險的話到第三步過濾建議還是都是用存儲過程參數(shù)化（或語句參 數(shù)化），因為到第三步的時候已經(jīng)不能確保100%防止注入了。還有的時候，經(jīng)常被群里的人或朋友問到如果我要傳遞多個ID進(jìn)去，比如批量刪除，有什么辦法，網(wǎng)上的解決辦法很多，我就不說了，主要有在存儲過程里字符串拆分組成臨時表，或者使用鄒健大哥的使用func,配合apply。這些都很復(fù)雜，實現(xiàn)起來需要很強的sql 根底，不過我的實現(xiàn)就是確保提交過的字符串只有數(shù)字和半角逗號組成即可。這樣就能確保 沒有注入可能，然后使用拼湊 sql的方式+語句參數(shù)化其他 where條件來確保安全。其實在這幾年我自己的開發(fā)歷程中，我自己總結(jié)我自己對sql注入的安全性認(rèn)識，經(jīng)歷了幾個認(rèn)識階段和慘痛教訓(xùn)。1最初的不知道什么叫 sql注入2使用過濾危險關(guān)鍵字來防止注入3使用參數(shù)化存儲過程4有些地方需要使用