本篇blog導航
~暴力破解&暴力破解漏洞概述
~基于表單的暴力破解實驗
~暴力破解的繞過和防范（驗證碼&Token）
~驗證碼的基礎知識
~驗證碼繞過（on client）
~驗證碼繞過（on server）
~防范措施
~措施總結
~token防爆破？
一、暴力破解&暴力破解漏洞概述
1、什么是暴力破解？
"暴力破解"是一攻擊具手段，在web攻擊中，一般會使用這種手段對應用系統的認證資訊進行獲取，其程序就是使用大量的認證資訊在認證介面進行嘗試登錄，直到得到正確的結果，為了提高效率，暴力破解一般會使用帶有字典的工具來進行自動化操作，
2、字典如何更有效，便于提高暴力破解的效率？
★常用的賬號密碼（弱口令），比如常用用戶名/密碼TOP500等；
★互聯網上被脫褲后賬號密碼（社工庫），比如csdn曾泄露的約600w用戶資訊；
★使用指定的字符使用工具按照指定的規則進行排列組合演算法生成的密碼，
3、什么是暴力破解漏洞？
如果一個網站沒有對登陸介面實施防暴力破解的措施，或者實施了不合理的措施，則我們稱該網站存在暴力破解漏洞，
4、什么措施可以防暴力破解？
★是否要求用戶設定了復雜的密碼；
★是否每次認證都使用安全的驗證碼；
★是否對嘗試登陸的行為進行判斷和限制；
★是否在必要的情況下采用了雙因素認證
……
5、暴力破解漏洞測驗流程？
（1）確認登陸介面的脆弱性
確認目標是否存在暴力破解的漏洞，（即被暴力破解的可能性）
例如：嘗試登陸-抓包-觀察驗證元素和response資訊，判斷是否存在被暴力破解的可能，
（2）對字典進行優化
根據實際的情況對字典進行優化，提高爆破的效率，
（3）工具自動化操作
配置自動化工具（例如：執行緒、超時時間、重試次數等等），進行自動化操作，
6、如何優化字典？
（1）根據注冊提示資訊進行優化
對目標站點進行注冊，搞清楚賬號密碼的一些限制，例如：目標站點要求密碼必須是6位以上，字母數字組合，則可以按照此規則優化字典，例如去掉不符合要求的密碼，
（2）如果爆破的是管理后臺，往往這種系統的管理員是admin/administrator/root的幾率比較高，可以使用這三個賬號+隨便一個密碼，嘗試登陸，查看回傳的結果，確定用戶名，
例如：
輸入xxx/xxxxwx回傳"用戶名或密碼錯誤"；
輸入admin/xxxf回傳"密碼錯誤"，則可以基本斷定用戶名是admin，
此時我們可以直接對密碼進行爆破，提高效率，
二、基于表單的暴力破解實驗
本次實驗我會詳細說明burp suite暴力破解模塊的使用步驟，以后再進行相同模塊使用的時候，就不這么詳細了，
1、打開我們的pikachu平臺，來到暴力破解下的基于表單的暴力破解模塊，
2、提示我們賬號密碼不存在，我們來到burp suite：Proxy->HTTP history，
3、嘗試使用burp suite的暴力破解模塊進行破解，
4、打開Intruder，給變數加上特殊符號；
5、選擇Attack type為Cluster bomb
6、準備兩個.txt檔案，命名為username.txt和password.txt，
因為是測驗，所以我是自己撰寫的簡單密碼本，這樣可以提高演示的速度，
7、做如下操作
（1）為第一個變數選擇username.txt這個密碼本，
（2）為第二個變數選擇password.txt這個密碼本，
8、我們回想一個問題：在破解完成后，如何判斷出哪一對用戶名和密碼是正確的呢？
我們這樣來判斷：
9、對執行緒并發數等引數進行設定（也可選擇使用默認的選項），執行破解程式，
10、分析結果，
11、用破解得到的username和password在網站上嘗試登陸，
三、暴力破解的繞過和防范（驗證碼&Token）
3.1 驗證碼的基礎知識：
★驗證碼是用來做什么的？
來驗證對方是一臺機器還是一個人！
√登錄暴力破解
√防止機器惡意注冊
★驗證碼的認證流程是?
①客戶端request登陸頁面，后臺生成驗證碼：
1.1后臺使用演算法生成圖片，并且將圖片response（回應）給客戶端，
1.2同時將演算法生成的值全域賦值保存到SESSION中，
②校驗驗證碼：
2.1客戶端將認證資訊和驗證碼一同提交，
2.2后臺對提交的驗證碼與SESSION里邊的進行比較，
③客戶端重新重繪頁面，再次生成新的驗證碼：
驗證碼演算法中一般包含隨機函式，所以每次重繪都會改變，
★只要有了驗證碼就可以防止被暴力破解嘛？
當然不是啦，你想什么呢？！你的驗證碼就一定安全嗎？
3.2 驗證碼繞過（on client）
一、OK，兄弟們，接下來就來演示不安全的驗證碼-on client-繞過實驗
1、來到pikachu實驗平臺暴力破解下的驗證碼繞過（on client）模塊，隨便輸入一個賬號和密碼+正確/錯誤的驗證碼，看看提示我們什么（回傳什么提示資訊）？
2、轉到burp suite，我們可以看到我們提交的表單資訊，
3、接下來我們來看原始碼，在網頁空白處右擊->查看網頁源代碼
4、我們知道它在前端進行了驗證碼的生成和驗證，那么他到底有沒有在后端同樣進行驗證呢？我們將burp suite抓到的POST請求資料包發送到Repester（資料包重放）模塊，
除此，我們來到實驗平臺的后端原始碼看一看（確認一下！！）
5、到此，我們基本可以肯定，在我們技術人眼里，這種在前端JS里邊的驗證碼就是狐假虎威，假把式，我們仍然可以使用burp suite里邊的暴力破解模塊進行破解，對于暴力破解的選項設定和前邊的"基于表單的暴力破解實驗"是一樣的，我就不多廢話了，
★通過上邊的演示實驗，我們知道寫在前端JS代碼里邊的驗證碼就是紙老虎，那么還有其他型別的驗證碼紙老虎嘛？
當然還有啦~~
（1）將驗證碼在cookie中泄露，容易被截取；
（2）將驗證碼在前端源代碼中泄露，容易被獲取，
到此，那么我們寫在后端的驗證碼驗證就一點安全嗎？好多人要崩潰了，你快別說了，剛剛說驗證碼生成驗證流程寫在后端安全，現在又說不安全~~
別急別急，驗證碼的生成驗證流程寫在后端可不是紙老虎了，只不過后端的驗證碼生成驗證流程如果沒有嚴謹的邏輯，那么也會被不法分子鉆了空子，
★后端驗證碼的常見的問題有什么？
（1）驗證碼在后臺不過期，可以在一段時間內甚至長期被使用；
（2）驗證碼校驗不合格，邏輯出現問題；
（3）驗證碼設計的太過簡單或者說有規律，容易被猜解，
3.3 驗證碼繞過（on server）
好的，接下來，我們繼續演示不安全的驗證碼-on server-繞過實驗
1、來到pikachu漏洞實驗平臺，打開暴力破解下的驗證碼繞過（on server）模塊，
2、我們輸入錯誤的用戶名、密碼、驗證碼，來到burp suite看看截取到的資料，
3、觀察到截取到的資料，我們發送到Repeater模塊，修改驗證碼的值進行資料重放，
4、我們再來看后臺的原始碼
5、那么有人問了，你不是繞過演示嘛，怎么到現在也沒有任何問題啊，別著急~~
6、我們重繪一下頁面，記錄出現的驗證碼，
7、來到burp suite下Repeater模塊，執行如圖片內的操作，
8、看起來也沒有什么問題哈！但是，如果你修改用戶名或者密碼后，而驗證碼的值我們不改變，又有什么結果呢？
9、ok，你知道怎么一回事了嘛？！我們將資料包發送到burp suite暴力破解模塊，進行破解，username和password仍然是變數，而驗證碼我們設定成一個重繪頁面后正確的常量就好了！
★上邊的問題到底是怎么回事呢？
我們來看代碼
★如何解決SESSION的問題呢？
四、防范措施
4.1 措施總結：
（1）設計安全的驗證碼（安全的流程+復雜而又可用的圖形）；
（2）對認證錯誤的提交進行計數并給出限制，例如：連續5次輸錯，鎖定一定時間；
（3）必要的情況下，使用雙因素認證；
4.2 token防爆破？
答案是否定的！！！！！！！
我們來看：
我們說雖然每一次token值都會變化，但是由于token回應到了前臺，我們在每一次嘗試前可以先獲得token的值，在提交，其實token對于暴力破解，是起不到防止的作用的，
我們說一般token一般在防止CSRF上會有比較好的功效，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/43235.html
標籤：其他