SQL注入式攻擊原理及防范5頁

1、SQL注入式攻擊原理及防范 【摘 要】本文介紹了SQL注入式攻擊的原理，結合實例闡述了SQL注入式攻擊的方法，并從代碼層和平臺層探討了SQL注入式攻擊的防范。 【關鍵詞】SQL；注入式；攻擊 1. SQL注入式攻擊的原理 進行SQL注入時一般會用到兩種方式：第一是手工注入，第二是工具注入。對于猜解管理員的密碼方面一般用Pangolin或者NBSI ，其總體思路是1：（1）掃描目標網絡信息（判斷是否存在SQL注入漏洞）；（2）判斷后臺數據庫類型；（3）發(fā)現(xiàn)WEB虛擬目錄；（4）上傳ASP木馬；（5）得到管理員權限。 詳細介紹如下： （1）SQL注入一般存在于形如：http：/xxx.xxx.xx

2、x/abc.asp？p=YY的網站中。 （2）在http：/xxx.xxx.xxx/abc.asp？p=YY 后面追加“and 1=1”，并訪問該網址即http：/xxx.xxx.xxx/abc.asp？p=YY and 1=1 應該與訪問原地址得到的結果相同。 （3）在http：/xxx.xxx.xxx/abc.asp？p=YY 后面追加“and 1=2”，并訪問該網址即http：/xxx.xxx.xxx/abc.asp？p=YY and 1=2應該與訪問原地址得到的結果不同，并提示數據庫錯誤。（2，3同時滿足則此網站必定存在SQL漏洞，可以進行sql注入攻擊） （4）訪問http：/xxx

3、.xxx.xxx/abc.asp？p=YY and exists （select * from 網站數據庫常用表段名） 網站數據庫常用表段名：admin users administrator 等，如果進入的網頁像步驟二一樣，是正常網頁，證明存在該表段名。找尋該SQL數據庫使用的表名，進而尋找網站的管理員名、密碼等信息。 （5）訪問http：/xxx.xxx.xxx/abc.asp？p=YY and exists （select 網站數據庫常用字段名 from 第4步找到的可入侵表名） 網站數據庫常用字段名：admin password username 等，如果進入的網頁像步驟2一樣，是正常

4、網頁，證明存在該字段名。找尋該SQL數據庫使用的字段名，進而尋找網站的管理員名、密碼等信息。 （6）訪問http：/xxx.xxx.xxx/abc.asp？p=YY and exists （select *from第4步找到的可入侵表名where第5步找到的可入侵字段名like _ ） 。 （7）訪問http：/xxx.xxx.xxx/可入侵后門字段名，找到網站后門。 （8）利用從數據庫中查到的敏感數據進入網站后門。 2. SQL注入式攻擊的簡單實例 這里我們舉一個比較常見的例子來簡要說明一下sql注入的原理。假如我們有一個users表，里面有兩個字段username和password。在我們

5、的java代碼中我們初學者都習慣用sql拼接的方式進行用戶驗證。比如： select id from users where username = +username + and password = + password + 這里的username和password都是我們存取從web表單獲得的數據。下面我們來看一下一種簡單的注入，如果我?在表單中username的輸入框中輸入 or 1=1- ，password的表單中隨便輸入一些東西，假如這里輸入123.此時我們所要執(zhí)行的sql語句就變成了 select id from users where username = or 1=1- and

6、 password = 123，我們來看一下這個sql，因為1=1是true，后面 and password = 123被注釋掉了。所以這里完全跳過了sql驗證。 3. SQL注入式攻擊的防范 從存在的實際情況來看，包括Web服務器管理員、數據庫服務器管理員、數據庫設計員、代碼程序員在內的所有工作人員都是防御體系的關鍵。 從Web應用程序的開發(fā)、部署、管理、維護多個方面進行審查，使程序SQL注入了漏洞最小化。我們從代碼層和平臺層兩個方面來闡述SQL注入攻擊的防御。 3.1代碼層防御 從Web數據庫管設計員和編寫代碼的角度來研究SQL注入攻擊防御的。 （1）使用參數化語句。前面講過動態(tài)字符串構造

7、是引發(fā)SQL注入漏洞的原因之一。作為一種更加安全的動態(tài)字符串構造方法，大多數現(xiàn)代編程語言和數據庫訪問API可以使用占位符或綁定變量來向SQL查詢提供參數（而非直接對用戶輸入進行操作）2，這些通常稱為參數化語句內容是更安全的方法，可以使用它們來避免或解決很多在應用中經常見到的SQL注入問題，并可以在大多數常見的情形中使用它們來替代現(xiàn)有的動態(tài)查詢。不過，值得注意的是，參數化語句是與一種向數據庫提供潛在的非安全參數（通常作為查詢或存儲過程調用）的方法。雖然它們不會修改傳遞給數據庫的內容，但如果正在調用的數據庫功能在存儲過程或函數中使用了動態(tài)SQL，則仍然可能出現(xiàn)SQL注入。 （2）輸出編碼 。處理驗

8、證應用受到的輸入以外，通常還需要對在應用的不同的模塊或部分間傳遞的內容進行編碼。在SQL注入語境中，將其發(fā)送給數據庫的內容進行編碼或“引用”是必要的操作，這樣可以保證內容被正確地處理。如有必要對包含字符串中的單引號進行編碼，可以使用兩個單引號替換單個單引號的方法來實現(xiàn)編碼的目的，從而有效阻止惡意用戶在特定的查詢中利用SQL注入，可以使用與下面類似的代碼在java中實現(xiàn)該目的： Sql=sql.replace（“ “， “ “）；。 3.2平臺層防御 服務器管理員應在IIS中為每個網站設置好執(zhí)行權限，一定別給靜態(tài)網站以腳本和可執(zhí)行權限。一般情況下給個“純腳本”權限就夠了，對于那些通過網站后臺管理

9、中心上傳的文件存放的目錄，就更謹慎一點吧，執(zhí)行權限設為無好了，這樣就能防止別有用心的人上傳ASP木馬，即使上傳了， ASP木馬也運行不了。由于SQL注入漏洞涉及整個網站安全，一旦黑客通過這個漏洞上傳了ASP木馬并運行起來，那整個網站也就完蛋了。所以責任心強的服務器管理員都應該十分謹慎的配置IIS的執(zhí)行權限。 同樣的謹慎態(tài)度也應該用在數據庫用戶的權限配置上（MS_SQL，ACCESS都沒有用戶權限配置）。如果PUBLIC權限已經夠用，那就不需要給更高的權限了，千萬別把SA級別的權限隨隨便便地給人家啊。要知道SA可是個等同管理員權限的角色，拿到了SA權限，幾乎就等于拿到主機的管理員帳號了。黑客可是能通過編程跨庫進行SQL注入的，如果把SA權限給了存在SQ