SQL注入黑客防線網站實例分析

今天到黑防站上去看看文章，可能出于“職業”習慣，看到?classid=1之類的東東就不由自主的想加點什么參數進去。
當在頁面http://www.hacker.com.cn/article/index.asp?classid=3&Nclassid=13加上①and 1=1和②and 1=2，都提示“處理 URL 時服務器上出錯。請和系統管理員聯絡”，看起來象已經過濾了非法提交，IIS也關閉了錯誤提示，再加上一個③單引號’的時候，也出同樣的錯誤提示，然而明顯與前兩個錯誤提示不同，因為前者顯示了黑客防線的Logo才提示錯誤，后者則是一個空白的錯誤提示頁。

這可是我從來沒碰到過的特殊情況，到底能不能注入呢？

換個角度，從程序員的思路是怎么寫這段程序的。首先，如果是用cint之類函數，那三種測試方法錯誤提示應該是完全一樣的；如果沒過濾的話，①②的結果應該是不一樣的。排除了幾種情況，最后覺得極可能是部分語句過濾，出現這種情況很可能是cint語句不小心放到SQL語句的后面，在SQL語句通過后，后面的語句報錯。

雖然還不很確定實際的程序是怎么寫的，但可以確定，這確實是一個注入點！

根據我寫的《SQL注入漏洞全接觸》，下一步就是判斷數據庫類型，因為錯誤提示都被屏蔽，只能通過系統表測試了，輸入：
 

http://www.hacker.com.cn/article/index.asp?classid=1 and (Select count(1) from sysobjects)>=0

提示出錯，沒出現Logo，說明是語句本身有錯，極可能是表sysobjects不存在，也就是說數據庫是Access，再拿一個Access應有的系統表試試（msysobjects在這個時候派不上用場，因為在Web下沒有權限讀取，SQL語句同樣不能通過，所以，必須換個有權限的表如MSysAccessObjects），果然，出現了黑防的Logo，證實數據庫確實是Access。
接下來的猜解就比較簡單了，用(count(1) from admin)>=0測試出admin表存在，表中有username、password字段。本來以為下面就是用最普通的Ascii解碼法猜解記錄，小Case，沒想到，一開始猜解，才發現這是最難啃的一塊骨頭：傳統的Ascii對比中，無論條件是否成立，語句都是可以正確執行的，它是利用ASP的出錯而非SQL語句的出錯來發現錯誤的，在這個頁面，不管你成不成立，都是顯示一個Logo然后報錯，根據無法做出判斷。
冥思苦想了半個鐘頭，終于想出一種方法，讓SQL語句有條件的報錯，先看看語句：

http://www.hacker.com.cn/article/index.asp?classid=1 and (select top 1 iif(asc(mid(username,1,1))>96,1,username) from admin)>0

寫出這個語句的時候，連我自己都好崇拜我自己，哈哈，別吐，解釋一下，asc(mid(username,1,1))這個都看得懂，取username第一位的ASCII碼，大于96的話，select出數字1，小于等于96的話，select輸出字符串username，然后，拿select出的值與0比較。
1與0都是數字型，當ASCII碼大于96的時候，SQL語句不會出錯；username則是字符型，當ASCII碼小于等于96的時候，SQL語句會出錯。所以，兩種情況的出錯提示是不同的，我們可以根據出錯提示判斷語句是否成立，從而逐步縮小每一位字符的范圍，得出username的值。
于是，根據上面所說的方法，得出username的值為：chr(98)+ chr(114)+ chr(105)+ chr(103)+ chr(104)+ chr(116)=bright，password的值為chr(109)+ chr(105)+ chr(110)+ chr(103)+ chr(116)+ chr(105) + chr(97)+ chr(110)=mingtian，解碼完成。