SQL注入漏洞全接觸--入門篇

　　隨着B/S模式應用開發的發展，使用這種模式編寫應用程序的程序員也愈來愈多。可是因爲這個行業的入門門檻不高，程序員的水平及經驗也良莠不齊，至關大一部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶能夠提交一段數據庫查詢代碼，根據程序返回的結果，得到某些他想得知的數據，這就是所謂的SQL Injection，即SQL注入。

 

　　SQL注入是從正常的WWW端口訪問，並且表面看起來跟通常的Web頁面訪問沒什麼區別，因此目前市面的防火牆都不會對SQL注入發出警報，若是管理員沒查看IIS日誌的習慣，可能被入侵很長時間都不會發覺。

 

　　可是，SQL注入的手法至關靈活，在注入的時候會碰到不少意外的狀況。能不能根據具體狀況進行分析，構造巧妙的SQL語句，從而成功獲取想要的數據，是高手與「菜鳥」的根本區別。

 

　　根據國情，國內的網站用ASP+Access或SQLServer的佔70%以上，PHP+MySQ佔L20%，其餘的不足10%。在本文，咱們從分入門、進階至高級講解一下ASP注入的方法及技巧，PHP注入的文章由NB聯盟的另外一位朋友zwell撰寫，但願對安全工做者和程序員都有用處。瞭解ASP注入的朋友也請不要跳過入門篇，由於部分人對注入的基本判斷方法還存在誤區。你們準備好了嗎?Let's Go...

 

　　入 門 篇

 

　　若是你之前沒試過SQL注入的話，那麼第一步先把IE菜單=>工具=>Internet選項=>高級=>顯示友好 HTTP 錯誤信息前面的勾去掉。不然，不論服務器返回什麼錯誤，IE都只顯示爲HTTP 500服務器錯誤，不能得到更多的提示信息。

 

　　第一節、SQL注入原理

 

　　如下咱們從一個網站www.19cn.com開始(注：本文發表前已徵得該站站長贊成，大部分都是真實數據)。

 

　　在網站首頁上，有名爲「IE不能打開新窗口的多種解決方法」的連接，地址爲：http://www.19cn.com/showdetail.asp?id=49，咱們在這個地址後面加上單引號’，服務器會返回下面的錯誤提示：

 

　　Microsoft JET Database Engine 錯誤 '80040e14'

 

　　字符串的語法錯誤 在查詢表達式 'ID=49'' 中。

 

　　/showdetail.asp，行8

 

　　從這個錯誤提示咱們能看出下面幾點：

 

　　1.網站使用的是Access數據庫，經過JET引擎鏈接數據庫，而不是經過ODBC。

 

　　2.程序沒有判斷客戶端提交的數據是否符合程序要求。

 

　　3.該SQL語句所查詢的表中有一名爲ID的字段。

 

　　從上面的例子咱們能夠知道，SQL注入的原理，就是從客戶端提交特殊的代碼，從而收集程序及服務器的信息，從而獲取你想到獲得的資料。

 

　　第二節、判斷可否進行SQL注入

 

　　看完第一節，有一些人會以爲：我也是常常這樣測試可否注入的，這不是很簡單嗎?其實，這並非最好的方法，爲何呢?

 

　　首先，不必定每臺服務器的IIS都返回具體錯誤提示給客戶端，若是程序中加了cint(參數)之類語句的話，SQL注入是不會成功的，但服務器一樣會報錯，具體提示信息爲處理 URL 時服務器上出錯。請和系統管理員聯絡。

 

　　其次，部分對SQL注入有一點了解的程序員，認爲只要把單引號過濾掉就安全了，這種狀況不爲少數，若是你用單引號測試，是測不到注入點的

 

　　那麼，什麼樣的測試方法纔是比較準確呢?答案以下：

 

　　① http://www.19cn.com/showdetail.asp?id=49

 

　　② http://www.19cn.com/showdetail.asp?id=49 and 1=1

 

　　③ http://www.19cn.com/showdetail.asp?id=49 and 1=2

 

　　這就是經典的1=一、1=2測試法了，怎麼判斷呢?看看上面三個網址返回的結果就知道了：

 

　　能夠注入的表現：

 

　　① 正常顯示(這是必然的，否則就是程序有錯誤了)

 

　　② 正常顯示，內容基本與①相同

 

　　③ 提示BOF或EOF(程序沒作任何判斷時)、或提示找不到記錄(判斷了rs.eof時)、或顯示內容爲空(程序加了on error resume next)

 

　　不能夠注入就比較容易判斷了，①一樣正常顯示，②和③通常都會有程序定義的錯誤提示，或提示類型轉換時出錯。

 

　　固然，這只是傳入參數是數字型的時候用的判斷方法，實際應用的時候會有字符型和搜索型參數，我將在中級篇的「SQL注入通常步驟」再作分析。

 

　　第三節、判斷數據庫類型及注入方法

 

　　不一樣的數據庫的函數、注入方法都是有差別的，因此在注入以前，咱們還要判斷一下數據庫的類型。通常ASP最常搭配的數據庫是Access和SQLServer，網上超過99%的網站都是其中之一。

 

　　怎麼讓程序告訴你它使用的什麼數據庫呢?來看看：

 

　　SQLServer有一些系統變量，若是服務器IIS提示沒關閉，而且SQLServer返回錯誤提示的話，那能夠直接從出錯信息獲取，方法以下：

 

　　http://www.19cn.com/showdetail.asp?id=49 and user>0

 

　　這句語句很簡單，但卻包含了SQLServer特有注入方法的精髓，我本身也是在一次無心的測試中發現這種效率極高的猜解方法。讓我看來看看它的含義：首先，前面的語句是正常的，重點在and user>0，咱們知道，user是SQLServer的一個內置變量，它的值是當前鏈接的用戶名，類型爲nvarchar。拿一個nvarchar的值跟int的數0比較，系統會先試圖將nvarchar的值轉成int型，固然，轉的過程當中確定會出錯，SQLServer的出錯提示是：將nvarchar值 」abc」 轉換數據類型爲 int 的列時發生語法錯誤，呵呵，abc正是變量user的值，這樣，不廢吹灰之力就拿到了數據庫的用戶名。在之後的篇幅裏，你們會看到不少用這種方法的語句。

 

　　順便說幾句，衆所周知，SQLServer的用戶sa是個等同Adminstrators權限的角色，拿到了sa權限，幾乎確定能夠拿到主機的Administrator了。上面的方法能夠很方便的測試出是不是用sa登陸，要注意的是：若是是sa登陸，提示是將」dbo」轉換成int的列發生錯誤，而不是」sa」。

 

　　若是服務器IIS不容許返回錯誤提示，那怎麼判斷數據庫類型呢?咱們能夠從Access和SQLServer和區別入手，Access和SQLServer都有本身的系統表，好比存放數據庫中全部對象的表，Access是在系統表[msysobjects]中，但在Web環境下讀該表會提示「沒有權限」，SQLServer是在表[sysobjects]中，在Web環境下可正常讀取。

 

　　在確承認以注入的狀況下，使用下面的語句：

 

　　http://www.19cn.com/showdetail.asp?id=49 and (select count(*) from sysobjects)>0

 

　　http://www.19cn.com/showdetail.asp?id=49 and (select count(*) from msysobjects)>0

 

　　若是數據庫是SQLServer，那麼第一個網址的頁面與原頁面http://www.19cn.com/showdetail.asp?id=49是大體相同的;而第二個網址，因爲找不到表msysobjects，會提示出錯，就算程序有容錯處理，頁面也與原頁面徹底不一樣。

 

　　若是數據庫用的是Access，那麼狀況就有所不一樣，第一個網址的頁面與原頁面徹底不一樣;第二個網址，則視乎數據庫設置是否容許讀該系統表，通常來講是不容許的，因此與原網址也是徹底不一樣。大多數狀況下，用第一個網址就能夠得知系統所用的數據庫類型，第二個網址只做爲開啓IIS錯誤提示時的驗證。

文章來自中國建站：http://www.jz123.cn/text/2630768.html