作者:
路人甲
·
2014/11/15 12:28
0x00.前言
目前由重複發包造成的問題主要有撞庫,爆破等。而隨著洩漏密碼的越來越多,這一類問題造成的影響也越來越嚴重,隨之大部分網站都做了對重複發包的防護。但是也有部分防護不完善,可以進行繞過。
0x01.基於IP的防護
許多網站為了防止重複發包這一問題,限制了每個ip的嘗試次數,如果失敗n次之後這個ip就暫時限制使用這一功能。
大部分php網站的獲取ip都與$_SERVER[‘HTTP_X_FORWARD_FRO’]和$_SERVER[‘HTTP_CLIENT_IP’]有關(只會點php....)。看到這兩個變數,大家都會想到http頭的X-Forward-For和client_ip。由此可見,我們可以利用在http頭修改這兩個引數來進行繞過。
http://zone.wooyun.org/content/12716
0x02.基於token的防護
token在cookie中
如果token基於cookie,由於cookie使用者可控,所以這樣的防護是沒有意義的。
token在session中
token在session中也分為兩種情況。
一種token不修改的,也就是你每次提交的資料之後token不會改變,這樣的話就沒有防護能力。
另外一種是提交一次,token重新整理一次,大概程式碼如下。
#!php
if($_SESSION['token']==$_POST['token']){
refreshToken();
if(isUser($_POST['username'],$_POST['password'])){
echo '登入成功';
}else{
echo '帳號或密碼錯誤';
}
}else{
echo 'token錯誤';
}
這樣的話,我們就不能直接進行重複發包了。不過由於token需要進行post提交,所以可以匹配出來網頁form中的token,然後再進行組合發包。
0x03 基於驗證碼的防護
1 驗證碼存在cookie中
有一部分網站把驗證碼的值寫在cookie中。只要輸入一次正確的驗證碼,然後抓包進行爆破就行了。
例如 ESPCMS cookie中的ecisp_home_seccode
2 驗證碼存在session中
部分程式設計師在用驗證碼的時候,驗證碼判斷完成之後不就行重新整理。
大概程式碼如下:
#!php
if($_SESSION['seccode']==$_POST['seccode']){
if(isUser($_POST['username'],$_POST['password'])){
echo '登入成功';
}else{
echo '帳號或密碼錯誤';
}
}esle{
echo '驗證碼錯誤';
}
這樣的話,我們只要填寫一次正確的驗證碼進行抓包,然後就可以直接重複發包了。
另外,大部分$_SESSION['seccode']都是由產生驗證碼的頁面來進行賦值的,但是有的程式設計師不對$_SESSION['sescode']的值進行為空判斷。
這樣的話,我們可以這樣繞過。
cookies清空,開啟burp,然後開啟登入頁面,隨後把獲取驗證碼的請求直接drop掉,這樣的話我們的$_SESSION['seccode']就是空了。然後抓包直接進行爆破。
http://wooyun.org/bugs/wooyun-2014-080424
3 驗證碼可以直接識別
這種情況就不多說了,烏雲就是例子。
http://zone.wooyun.org/content/11826
4 驗證碼設計缺陷
驗證碼設計存在缺陷,可以透過某種條件產生一個特定的值。
http://wooyun.org/bugs/wooyun-2014-080211
0x04.基於可預測值防護
舉例幾種常見的情況
透過回答指定的問題,來進行驗證。常見的有網站域名的,網站標題等等。由於隨機性太弱,所以我們可以設定其為其實一個問題的答案,然後進行爆破就行了。還有更直接的,直接在頁面中這樣輸出 我們網站的域名是(答案為xxx.com),這樣的話就類似於2.2的繞過方法。
1+1 3+1之類可預測結果範圍的情況。
有的網站會讓你寫出圖形中某一特徵的數值或者字母。這樣的話變相的降低了驗證碼的可隨機性。例如驗證碼為sx4g中的數字。數字一共只有10個,我們只要設定為其中一個為固定值進行測試。
這一問題主要造成的原因是因為值或者值的範圍可預測,我們就可以設定一個固定的值作為答案,然後進行測試。
本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!