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頭修改這兩個引數來進行繞過。
0x02.基於token的防護
token在cookie中如果token基於cookie，由於cookie使用者可控，所以這樣的防護是沒有意義的。
token在session中
token在session中也分為兩種情況。
一種token不修改的，也就是你每次提交的資料之後token不會改變，這樣的話就沒有防護能力。
另外一種是提交一次，token重新整理一次，大概**如下。
if($_session['token']==$_post['token'])else}else
這樣的話，我們就不能直接進行重**包了。不過由於token需要進行post提交，所以可以匹配出來網頁form中的token，然後再進行組合發包。
0x03 基於驗證碼的防護
1 驗證碼存在cookie中
有一部分**把驗證碼的值寫在cookie中。只要輸入一次正確的驗證碼，然後抓包進行爆破就行了。
例如 espcms cookie中的ecisp_home_seccode
2 驗證碼存在session中
部分程式設計師在用驗證碼的時候，驗證碼判斷完成之後不就行重新整理。
大概**如下:
if($_session['seccode']==$_post['seccode'])else}esle
這樣的話，我們只要填寫一次正確的驗證碼進行抓包，然後就可以直接重**包了。
另外，大部分$_session['seccode']都是由產生驗證碼的頁面來進行賦值的，但是有的程式設計師不對$_session['sescode']的值進行為空判斷。
這樣的話，我們可以這樣繞過。
cookies清空，開啟burp，然後開啟登入頁面，隨後把獲取驗證碼的請求直接drop掉，這樣的話我們的$_session['seccode']就是空了。然後抓包直接進行爆破。
3 驗證碼可以直接識別
這種情況就不多說了，烏雲就是例子。
4 驗證碼設計缺陷
驗證碼設計存在缺陷，可以通過某種條件產生乙個特定的值。
0x04.基於可**值防護
舉例幾種常見的情況
通過回答指定的問題，來進行驗證。常見的有**網域名稱的，**標題等等。由於隨機性太弱，所以我們可以設定其為其實乙個問題的答案，然後進行爆破就行了。還有更直接的，直接在頁面中這樣輸出 我們**的網域名稱是(答案為***.com)，這樣的話就類似於2.2的繞過方法。
1+1 3+1之類可**結果範圍的情況。
有的**會讓你寫出圖形中某一特徵的數值或者字母。這樣的話變相的降低了驗證碼的可隨機性。例如驗證碼為sx4g中的數字。數字一共只有10個，我們只要設定為其中乙個為固定值進行測試。這一問題主要造成的原因是因為值或者值的範圍可**，我們就可以設定乙個固定的值作為答案，然後進行測試。
關於重複發包的防護與繞過
路人甲 2014 11 15 12 28 目前由重 包造成的問題主要有撞庫，爆破等。而隨著洩漏密碼的越來越多，這一類問題造成的影響也越來越嚴重，隨之大部分 都做了對重 包的防護。但是也有部分防護不完善，可以進行繞過。許多 為了防止重 包這一問題，限制了每個ip的嘗試次數，如果失敗n次之後這個ip就暫...
charles 批量重複請求 重複發包工具
本文參考 charles 批量請求 重 包工具 repeat charles 讓你選擇乙個請求並重複,在測試後端介面的時候非常有用 charles將請求重新傳送到伺服器，並將響應顯示為新請求。如果您進行後端更改並希望測試它們，用了charles後，你就沒必要在瀏覽器 或其他客戶端 中重複該請求，ch...
防止重複傳送Ajax請求的解決方案
在頁面中有多個按鈕，點選該按鈕可以非同步的去服務端讀取資料，然後在前端將資料展示出來。每個按鈕點選請求的頁面都是同乙個，但是請求的引數不同，所以返回的內容就不同。在連續點選多個按鈕的時候就會發出多個非同步請求。那麼根據請求返回的快慢 因為不同按鈕引數不同，返回內容不同，所以會有快慢之分 資料會依次的...