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

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

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

雖然還不很確定實(shí)際的程序是怎么寫的，但可以確定，這確實(shí)是一個注入點(diǎn)！

根據(jù)我寫的《SQL注入漏洞全接觸》，下一步就是判斷數(shù)據(jù)庫類型，因?yàn)殄e誤提示都被屏蔽，只能通過系統(tǒng)表測試了，輸入：
 

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

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

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出數(shù)字1，小于等于96的話，select輸出字符串username，然后，拿select出的值與0比較。
1與0都是數(shù)字型，當(dāng)ASCII碼大于96的時候，SQL語句不會出錯；username則是字符型，當(dāng)ASCII碼小于等于96的時候，SQL語句會出錯。所以，兩種情況的出錯提示是不同的，我們可以根據(jù)出錯提示判斷語句是否成立，從而逐步縮小每一位字符的范圍，得出username的值。
于是，根據(jù)上面所說的方法，得出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，解碼完成。

最新評論