Ajax時代 SQL注入依然是隱患

許多網站程序在編寫時，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶能夠提交一段數據庫查詢代碼（通常是在瀏覽器地址欄進行,經過正常的www端口訪問），根據程序返回的結果，得到某些想得知的數據，這就是所謂的SQL Injection，即SQL注入。

    SQL注入經過網頁對網站數據庫進行修改。它可以直接在數據庫中添加具備管理員權限的用戶，從而最終得到系統管理員權限。黑客能夠利用得到的管理員權限任意得到網站上的文件或者在網頁上加掛木馬和各類惡意程序，對網站和訪問該網站的網友都帶來巨大危害。

在咱們的實際生活中，尋找「ajax+sql注入」的例子並不困難，並且其尋找過程也很簡單，只需通過如下五個步驟便可：

    1， 搜索「用戶註冊」，搜索出來的記錄一個一個打開。

    2， 測試是否使用了Ajax。

    3， 找到check頁面。

    4， 在check頁面裏的提交用戶名參數那裏，給用戶名作下手腳而後在地址欄從新提交。

    5， 若是發現500錯誤（web服務器默認錯誤—服務器內部錯誤），就說明他存在注入漏洞。

    按照上面的步驟，居然發現了某大型IT網站的注入漏洞！步驟寫的簡單，具體的方法也有取巧的部分，首先打開找到的網頁（固然是用戶註冊頁面），輸入會員名稱。繼續輸入密碼，彈出消息框：

 

Ajax的做用就在於「不刷新的狀況下，異步傳輸數據，通過服務器處理後，獲得返回信息，提示給用戶」。看到這個消息框，我第一個想到的就是Ajax。前面說過，在檢測的時候，能夠取巧，取巧的地方就在過程當中最複雜的地方「翻看源代碼」。若是每一個網頁都看看源代碼，而後找js寫的方法（函數），再經過方法（函數）找check頁面，那還不把人累死。因而我想到了「WinSock Expert v0.6 beta1」，這個工具能夠截取應用程序經過tcp或udp傳輸的數據，瀏覽器訪問網站的數據固然可以截獲：     1， 關閉全部的瀏覽器，而後打開一個瀏覽器訪問「用戶註冊頁面」，即上一個截圖給出的頁面。這樣作是爲了在選擇進程時，只能看到一個IE進程。     2， 先不要輸入用戶名，打開「WinSock Expert v0.6 beta1」。單擊：         3， 能夠看到全部當前運行的進程，選中瀏覽器「IEXOLORE.EXE」。選擇右下角的「open」 ：         4， 這個界面就是截獲數據的界面，並且如今已經開始截獲數據，因此不要再去訪問任何頁面。     5， 回到瀏覽器頁面，輸入用戶名「fdsa」（隨便找個必定能被人使用的，好比admin也能夠）後把光標移到密碼輸入框。彈出本文第一個圖片所示消息框「對不起，此用戶已經被人使用」，不要點肯定。     6， 再回到「WinSock Expert v0.6 beta1」工具界面看到有三條數據：         7， 第一個和最後一個，不去管它，由於它們沒有訪問頁面。單看第2條數據。ID是指序號；status指狀態，這裏三條都是發送的數據（send）；packetshex是發送數據的16進制編碼，看不懂不須要看；packets text就是咱們可以看懂的東西了；address固然是服務器ip地址。     8， 選中第二條數據，由於這條數據的第一行顯示「GET /checkuser2」，表示數據是以「GET」形式提交給服務器，也就是說這條信息是IE剛纔提交的數據，因此咱們查看它。

9， 選中後就能在軟件最下面的地方看到數據。複製出來解釋給你們：

 

 

    詳細參數請參照HTTP頭的文章，這裏只解釋能用到的：

    第一行是IE訪問的頁面「/checkuser2.jsp?checkemail=fdsa」，以及IE是以GET形式提交的數據，剛輸入的用戶名「fdsa」。

    10， 打開http://pass.****.com.cn/checkuser2.jsp?checkemail=fdsa，彈出消息框。

    11， 果真能夠在這裏提交參數，把「fdsa」替換爲「fdsa’」提交：

 

 

    12， 500錯誤頁面，存在SQL注入！

    看似很麻煩，有12步，可是比找代碼要簡單的多，直接獲取了check頁面，和參數。

    分析服務器返回頁面的代碼：

 

 

    既然肯定存在注入漏洞，就要找他頁面上的Ajax，以便分析出結後寫文章用。查找註冊頁面上的「會員名」，查看輸入框代碼：

 

 調用了RegCheckUserExist2方法，搜索方法找不到記錄。說明是包含了js文件，搜索「<script>」，獲取js文件：

 

 

    注意我描紅的地方，RegCheckUserExist2方法在/js/chkcus.js文件裏，代碼：

 

 

    Form是在調用RegCheckUserExist2時傳入的參數，整個流程以下：

 

 

    由於提交是在一個隱藏的iframe（寬和高都是0），因此咱們看不到頁面刷新，是個僞Ajax。可是其效果和Ajax同樣，都是在用戶不知道的狀況下給服務器提交，只是Ajax是異步的，在提交驗證的時候用戶感受不到，而這裏是同步的，用戶要等待返回結果後，才能進行下一步操做。即便這裏用了Ajax，仍然會存在sql注入漏洞，緣由是問題出在服務器的驗證這裏。我本來打算寫的「ajax可能引起的注入漏洞」和這裏所具有的環境基本類似。這有點相似於面向對象裏的繼承，一個父類存在漏洞，僞Ajax和Ajax兩個類都繼承了類（這個漏洞），雖然他們都重寫了「驗證的過程」