SQL注入黑客防線網(wǎng)站實(shí)例分析

今天到黑防站上去看看文章,可能出于“職業(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 時(shí)服務(wù)器上出錯(cuò)。請(qǐng)和系統(tǒng)管理員聯(lián)絡(luò)”,看起來象已經(jīng)過濾了非法提交,IIS也關(guān)閉了錯(cuò)誤提示,再加上一個(gè)③單引號(hào)’的時(shí)候,也出同樣的錯(cuò)誤提示,然而明顯與前兩個(gè)錯(cuò)誤提示不同,因?yàn)榍罢唢@示了黑客防線的Logo才提示錯(cuò)誤,后者則是一個(gè)空白的錯(cuò)誤提示頁。
這可是我從來沒碰到過的特殊情況,到底能不能注入呢?
換個(gè)角度,從程序員的思路是怎么寫這段程序的。首先,如果是用cint之類函數(shù),那三種測(cè)試方法錯(cuò)誤提示應(yīng)該是完全一樣的;如果沒過濾的話,①②的結(jié)果應(yīng)該是不一樣的。排除了幾種情況,最后覺得極可能是部分語句過濾,出現(xiàn)這種情況很可能是cint語句不小心放到SQL語句的后面,在SQL語句通過后,后面的語句報(bào)錯(cuò)。
雖然還不很確定實(shí)際的程序是怎么寫的,但可以確定,這確實(shí)是一個(gè)注入點(diǎn)!
根據(jù)我寫的《SQL注入漏洞全接觸》,下一步就是判斷數(shù)據(jù)庫類型,因?yàn)殄e(cuò)誤提示都被屏蔽,只能通過系統(tǒng)表測(cè)試了,輸入:
http://www.hacker.com.cn/article/index.asp?classid=1 and (Select count(1) from sysobjects)>=0
提示出錯(cuò),沒出現(xiàn)Logo,說明是語句本身有錯(cuò),極可能是表sysobjects不存在,也就是說數(shù)據(jù)庫是Access,再拿一個(gè)Access應(yīng)有的系統(tǒng)表試試(msysobjects在這個(gè)時(shí)候派不上用場(chǎng),因?yàn)樵赪eb下沒有權(quán)限讀取,SQL語句同樣不能通過,所以,必須換個(gè)有權(quán)限的表如MSysAccessObjects),果然,出現(xiàn)了黑防的Logo,證實(shí)數(shù)據(jù)庫確實(shí)是Access。
接下來的猜解就比較簡(jiǎn)單了,用(count(1) from admin)>=0測(cè)試出admin表存在,表中有username、password字段。本來以為下面就是用最普通的Ascii解碼法猜解記錄,小Case,沒想到,一開始猜解,才發(fā)現(xiàn)這是最難啃的一塊骨頭:傳統(tǒng)的Ascii對(duì)比中,無論條件是否成立,語句都是可以正確執(zhí)行的,它是利用ASP的出錯(cuò)而非SQL語句的出錯(cuò)來發(fā)現(xiàn)錯(cuò)誤的,在這個(gè)頁面,不管你成不成立,都是顯示一個(gè)Logo然后報(bào)錯(cuò),根據(jù)無法做出判斷。
冥思苦想了半個(gè)鐘頭,終于想出一種方法,讓SQL語句有條件的報(bào)錯(cuò),先看看語句:
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
寫出這個(gè)語句的時(shí)候,連我自己都好崇拜我自己,哈哈,別吐,解釋一下,asc(mid(username,1,1))這個(gè)都看得懂,取username第一位的ASCII碼,大于96的話,select出數(shù)字1,小于等于96的話,select輸出字符串username,然后,拿select出的值與0比較。
1與0都是數(shù)字型,當(dāng)ASCII碼大于96的時(shí)候,SQL語句不會(huì)出錯(cuò);username則是字符型,當(dāng)ASCII碼小于等于96的時(shí)候,SQL語句會(huì)出錯(cuò)。所以,兩種情況的出錯(cuò)提示是不同的,我們可以根據(jù)出錯(cuò)提示判斷語句是否成立,從而逐步縮小每一位字符的范圍,得出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,解碼完成。
相關(guān)文章
ASP+PHP 標(biāo)準(zhǔn)sql注入語句(完整版)
這里為大家分享一下sql注入的一些語句,很多情況下由于程序員的安全意識(shí)薄弱或基本功不足就容易導(dǎo)致sql注入安全問題,建議大家多看一下網(wǎng)上的安全文章,最好的防范就是先學(xué)2017-05-19mysql 注入報(bào)錯(cuò)利用方法總結(jié)
這篇文章主要介紹了mysql 注入報(bào)錯(cuò)利用方法總結(jié)的相關(guān)資料,需要的朋友可以參考下2016-10-08- SQL注入是從正常的WWW端口訪問,而且表面看起來跟一般的Web頁面訪問沒什么區(qū)別,所以目前市面的防火墻都不會(huì)對(duì)SQL注入發(fā)出警報(bào),如果管理員沒查看IIS日志的習(xí)慣,可能被入2016-05-21
- 這篇文章主要為大家介紹了SQL注入測(cè)試實(shí)例分析,對(duì)于數(shù)據(jù)庫安全非常重要,需要的朋友可以參考下2014-08-06
- sqlmap 是一個(gè)自動(dòng)SQL 射入工具。本文收集了一些利用Sqlmap做注入測(cè)試的TIPS,其中也包含一點(diǎn)繞WAF的技巧,便于大家集中查閱,歡迎接樓補(bǔ)充、分享。2014-07-29
- 畢業(yè)開始從事winfrm到今年轉(zhuǎn)到 web ,在碼農(nóng)屆已經(jīng)足足混了快接近3年了,但是對(duì)安全方面的知識(shí)依舊薄弱,事實(shí)上是沒機(jī)會(huì)接觸相關(guān)開發(fā)……必須的各種借口。這幾天把sql注入2012-11-06
- java防SQL注入,最簡(jiǎn)單的辦法是杜絕SQL拼接,SQL注入攻擊能得逞是因?yàn)樵谠蠸QL語句中加入了新的邏輯2012-08-10
- SQL注入攻擊的危害性很大。在講解其防止辦法之前,數(shù)據(jù)庫管理員有必要先了解一下其攻擊的原理。這有利于管理員采取有針對(duì)性的防治措施2012-07-10
- web 頁面 一些sql注入語句小結(jié),對(duì)于開發(fā)人員來說一定要注意的事項(xiàng)。2012-03-12
手動(dòng)mysql 高級(jí)注入實(shí)例分析
為了 方便 自己隨手寫了個(gè) sql.php注入點(diǎn) 。經(jīng)典的 id沒有過濾 造成 sql語句帶入?yún)?shù) 形成注入, 對(duì)了 大家導(dǎo)入test.sql 這個(gè)數(shù)據(jù)庫文件吧2010-08-04