目前由重復發包造成的問題主要有撞庫，爆破等。而隨著泄漏密碼的越來越多，這一類問題造成的影響也越來越嚴重，隨之大部分網站都做了對重復發包的防護。但是也有部分防護不完善，可以進行繞過。
許多網站為了防止重復發包這一問題，限制了每個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
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，然后再進行組合發包。
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
舉例幾種常見的情況
通過回答指定的問題，來進行驗證。常見的有網站域名的，網站標題等等。由于隨機性太弱，所以我們可以設定其為其實一個問題的答案，然后進行爆破就行了。還有更直接的，直接在頁面中這樣輸出 我們網站的域名是(答案為xxx.com)，這樣的話就類似于2.2的繞過方法。
1+1 3+1之類可預測結果范圍的情況。
有的網站會讓你寫出圖形中某一特征的數值或者字母。這樣的話變相的降低了驗證碼的可隨機性。例如驗證碼為sx4g中的數字。數字一共只有10個，我們只要設定為其中一個為固定值進行測試。 這一問題主要造成的原因是因為值或者值的范圍可預測，我們就可以設定一個固定的值作為答案，然后進行測試。