解讀ASP.NET網站程序防SQL注入式攻擊方法(2)_.Net教程
推薦:解讀asp.net中的觀察者模式在asp.net中實現觀察者模式?難道asp.net中的觀察者模式有什么特別么?嗯,基于Http協議的Application難免有些健忘,我是這樣實現的,不知道有沒有更好的辦法? 先談談需求吧,以免陷入
⑴ 對于動態構造SQL查詢的場合,可以使用下面的技術:
第一:替換單引號,即把所有單獨出現的單引號改成兩個單引號,防止攻擊者修改SQL命令的含義。再來看前面的例子,“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”顯然會得到與“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的結果。
第二:刪除用戶輸入內容中的所有連字符,防止攻擊者構造出類如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之類的查詢,因為這類查詢的后半部分已經被注釋掉,不再有效,攻擊者只要知道一個合法的用戶登錄名稱,根本不需要知道用戶的密碼就可以順利獲得訪問權限。
第三:對于用來執行查詢的數據庫帳戶,限制其權限。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執行的操作,因而也就防止了原本用于執行SELECT命令的地方卻被用于執行INSERT、UPDATE或DELETE命令。
⑵ 用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外,它還使得數據庫權限可以限制到只允許特定的存儲過程執行,所有的用戶輸入必須遵從被調用的存儲過程的安全上下文,這樣就很難再發生注入式攻擊了。
⑶ 限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符,那么不要認可表單中輸入的10個以上的字符,這將大大增加攻擊者在SQL命令中插入有害代碼的難度。
⑷ 檢查用戶輸入的合法性,確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和服務器端都執行——之所以要執行服務器端驗證,是為了彌補客戶端驗證機制脆弱的安全性。
在客戶端,攻擊者完全有可能獲得網頁的源代碼,修改驗證合法性的腳本(或者直接刪除腳本),然后將非法內容通過修改后的表單提交給服務器。因此,要保證驗證操作確實已經執行,唯一的辦法就是在服務器端也執行驗證。你可以使用許多內建的驗證對象,例如RegularExpressionValidator,它們能夠自動生成驗證用的客戶端腳本,當然你也可以插入服務器端的方法調用。如果找不到現成的驗證對象,你可以通過CustomValidator自己創建一個。
⑸ 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據,然后再將它與數據庫中保存的數據比較,這相當于對用戶輸入的數據進行了“消毒”處理,用戶輸入的數據不再對數據庫有任何特殊的意義,從而也就防止了攻擊者注入SQL命令。System.Web.Security.FormsAuthentication類有一個HashPasswordForStoringInConfigFile,非常適合于對輸入數據進行消毒處理。
⑹ 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄,但實際返回的記錄卻超過一行,那就當作出錯處理。
分享:解讀Asp.net教程:設計IP地址屏蔽功能出于安全考慮,幾乎每個動態網站都具備IP地址屏蔽功能,而網上流傳的很多關于該功能的教程大都采用字符串保存和驗證IP地址,我認為這是不太科學的,我試圖找到最佳的設計方案。 “I
- asp.net如何得到GRIDVIEW中某行某列值的方法
- .net SMTP發送Email實例(可帶附件)
- js實現廣告漂浮效果的小例子
- asp.net Repeater 數據綁定的具體實現
- Asp.Net 無刷新文件上傳并顯示進度條的實現方法及思路
- Asp.net獲取客戶端IP常見代碼存在的偽造IP問題探討
- VS2010 水晶報表的使用方法
- ASP.NET中操作SQL數據庫(連接字符串的配置及獲取)
- asp.net頁面傳值測試實例代碼
- DataGridView - DataGridViewCheckBoxCell的使用介紹
- asp.net中javascript的引用(直接引入和間接引入)
- 三層+存儲過程實現分頁示例代碼
- 相關鏈接:
- 教程說明:
.Net教程-解讀ASP.NET網站程序防SQL注入式攻擊方法(2)
。