[TOC]
## 暴力破解
暴力猜解簡單來說就是將密碼進行逐個推算,直到找出真正的密碼為止
### 1、暴力破解注意事項:
1. 破解前一定要有一個有效的字典;
2. 判斷用戶賬號和網站情況
是否設置了復雜的密碼、網站是否存在驗證碼、嘗試登錄的行為是否有限制、網站是否雙因素認證、Token值等等。
有些公司內網服務的密碼是先統一默認密碼給員工,再讓他們自己更改,可也可能出現漏洞
>等保中對管理員后臺有雙因素認證要求,例如只允許某個IP訪問,通過堡壘機,手機短信等
3. 對目標網站進行注冊、改密、找密等流程
搞清楚帳號密碼的一些限制,比如目標站點要求密碼必須是8位以上,字母數字組合等
用戶名修改密碼新舊密碼是不允許一樣的,也可能出現漏洞
4. 確定要破解的賬號是否存在
測試正確賬號與錯誤賬號的返回信息是否相同等,想辦法先確定要破解的賬號是存在的(特別是破解管理員賬號時)
通過企業網站所留郵箱命名規則,也可以判斷系統賬號規則
4. 破解管理后臺密碼
可使用admin/administrator/root帳號機率較高,可以使用這三個帳號+密碼字典進行暴力破解
### C/S架構和B/S架構
C/S就是“Client/Server”的縮寫,即“客戶端/服務器”模式。
B/S就是“Browser/Server”的縮寫,即“瀏覽器/服務器”模式。
**C/S與B/S的結構區別:**
* 硬件環境不同
C/S通常是建立在專用的網絡上,小范圍的網絡環境。而B/S是建立在廣域網上的,適應范圍強,通常有操作系統和瀏覽器就行;?
* 安全要求不同
C/S結構比B/S結構更安全,因為用戶群相對固定,對信息的保護更強;而B/S結構面向的范圍廣,所以安全性比較低;?
* 系統維護不同
B/S結構維護升級比較簡單,而C/S結構維護升級相對困難。
### 暴力破解分類
1. 基于表單的暴力破解
2. 基于驗證碼暴力破解
on client常見問題:不安全的前端js實現驗證碼;不安全的將驗證碼在cookie中泄露;不安全的將驗證碼在前端源代碼中泄露
on server常見問題:驗證碼在后臺不過期,導致長期使用(php默認session是24分鐘過期);驗證碼校驗不嚴格,邏輯出現問題;驗證碼設計的太過簡單和有規律的被猜解
3. 基于Token破解
由于token值輸出在前端源代碼中,容易被獲取,因此也就失去了防暴力破解的意義,一般Token在防止CSRF上會有比較好的功效。
注意:線程數設為1;Grep-Extract設置好開始token" value=" 結束為" /> ;有郊載荷設為遞歸搜索
“token” value="
4. 基于系統、數據庫、中間件等第三方服務破解
系統漏洞掃描器自帶暴力破解、Bruter工具、hydra
## 驗證碼安全:
驗證碼是一種區分用戶是計算機還是人的公共全自動程序。可以防止:惡意破解密碼、刷票、論壇灌水,有效防止某個黑客對某一個特定注冊用戶用特定程序暴力破解方式進行不斷的登陸嘗試
### 驗證碼的原理:
1. 客戶端發起一個請求
2. 服務端響應并創建一個新的SessionID同時生成一個隨機驗證碼。
3. 服務端將驗證碼和SessionID一并返回給客戶端
4. 客戶端提交驗證碼連同SessionID給服務端
5. 服務端驗證驗證碼同時銷毀當前會話,返回給客戶端結果,如果不銷毀則默認24分鐘
### 驗證碼可能會出現的問題
1. 客戶端生成驗證碼
驗證碼由客戶端js生成并且僅僅在客戶端用js驗證,通過抓包或禁用js,都可繞過
2. 驗證碼輸出客戶端
無論出于什么考慮,都不應該把驗證碼的內容發送到客戶端cookie或輸出到response headers的其他字段。
比如,寫入驗證碼的MD5值、 Base64轉碼等,太容易被攻擊者逆向破解,得到原值。
3. 驗證碼輸出在cookie中
有些系統默認不顯示驗證碼,而是在用戶校驗錯誤一定次數之后再出現。那如何判斷用戶已經錯誤幾次了呢?沒有經驗的開發可能這樣做:
①在cookie中寫入一個標記,比如loginErr = 1,后續錯誤累加
②在session中寫入一個標記,例如loginErr = 1,后續錯誤累加
問題在于,要是攻擊者不帶Cookie提交HTTP請求呢?或者是,攻擊者不更新Cookie中loginErr的值反復提交呢?這樣程序會因為無從獲取Cookie/sessionID,會認為攻擊者是首次訪問。無論什么時候,驗證碼都不會出現!
4. 驗證碼不過期,沒有及時銷毀會話導致驗證碼復用(php默認有24分鐘)
基本的認識是:一張驗證碼,只能使用一次。使用之后,立即過期,不可再次使用。
5. 沒有進行非空判斷
很多時候,我們會遺留掉了驗證過程中驗證碼為空的情況,比如去掉cookie中的某些值或者請求中驗證碼參數。
6. 產生的驗證碼問題集內的答案非常有限
例如就4個選項ABCD,那么一直用同一個序號破解,總有25%的概率正確
7. 驗證碼太簡單,容易被機器識別
例如使用pkav這款安全軟件,就可以很容易的識別大部分簡單驗證碼
## 暴力破解安全防范:
* 強制要求輸入驗證碼或者手機otp,否則,必須實施IP策略。 注意不要被X-Forwaded-For繞過了!
* 驗證碼只能用一次,用完立即過期!不能再次使用
* 驗證碼不要太弱。扭曲、變形、干擾線條、干擾背景色、變換字體等。
* 大網站最好統一安全驗證碼,各處使用同一個驗證碼接口。
* 要求用戶設置復雜的密碼;
* 對嘗試登錄的行為進行判斷和限制(如:連續5次錯誤登錄,進行賬號鎖定或IP地址鎖定等);
* 采用了雙因素認證;
- src導航站
- kali和msf
- 信息收集
- 收集域名信息
- Whois 查詢
- 備案信息查詢
- 信用信息查詢
- IP反查站點的站
- 瀏覽器插件
- 收集子域名信息
- 在線平臺
- 工具枚舉
- ssl與證書透明度
- DNS歷史解析
- DNS域傳送漏洞
- C段探測
- JS文件域名&ip探測
- 搜索引擎&情報社區
- google黑客
- 威脅情報
- 鐘馗之眼
- 收集相關應用信息
- 微信公眾號&微博
- APP收集&反編譯
- 收集常用端口信息
- 常見端口&解析&總結
- 掃描工具
- 網絡空間引擎搜索
- 瀏覽器插件
- nmap掃描
- 收集敏感信息
- 源碼泄露
- 郵箱信息收集
- 備份文件泄露
- 目錄&后臺掃描
- 公網網盤
- 歷史資產
- 指紋&WAF&CDN識別
- 指紋識別
- CDN識別
- 繞過CDN查找真實IP
- WAF識別
- 漏洞資源和社工
- 漏洞公共資源庫
- 社會工程
- 資產梳理
- 各種對滲透有幫助的平臺
- 掃描器
- 掃描器對比
- AppScan(IBM)_web和系統
- AWVS_web掃描
- X-Scan_系統掃描
- WebInspect_HP_WEB
- Netsparker_web
- WVSS_綠盟_web
- 安恒明鑒
- Nessus_系統
- nexpose_系統
- 啟明天鏡_web_系統
- SQL注入
- 常用函數
- sql注入步驟
- union注入和information_schema庫
- 函數和報錯注入
- SQL盲注
- 其他注入方式
- 防止SQL注入解決方案
- Access數據庫注入
- MSSQL數據庫注入
- MYSQL數據庫注入
- 神器SQLmap
- xss跨站腳本攻擊
- xss原理和分類
- xss案例和修復
- xss繞過技巧
- xss案例
- 文件上傳下載包含
- 常有用文件路徑
- 文件上傳漏洞
- 文件下載漏洞
- 文件包含漏洞
- upload-labs上傳漏洞練習
- XXE、SSRF、CSRF
- SSRF原理基礎
- SSRF案例實戰
- CSRF原理基礎
- CSRF案例及防范
- XXE之XML_DTD基礎
- XXE之payload與修復
- XXE結合SSRF
- 遠程命令執行與反序列化
- 遠程命令和代碼執行漏洞
- 反序列化漏洞
- 驗證碼與暴力破解
- 爆破與驗證碼原理
- CS架構暴力破解
- BS架構暴力破解
- WEB編輯器漏洞
- 編輯器漏洞基礎
- Ewebeditor編輯器
- FCKeditor編輯器
- 其他編輯器
- web中間件漏洞
- 中間件解析漏洞
- Tomcat常見的漏洞總結
- Jboss漏洞利用總結
- Weblogic漏洞利用總結
- WEB具體步驟
- 旁注和越權
- CDN繞過
- 越權與邏輯漏洞
- WEB應用常見其他漏洞
- WEB登陸頁面滲透思路
- 獲取WEBshell思路
- 社工、釣魚、apt
- 社工和信息收集
- 域名欺騙
- 釣魚郵件
- 一些釣魚用的掛馬工具
- 代碼審計
- 代碼審計工具
- WAF繞過
- WAF基礎及云WAF
- 各種WAF繞過方法
- 繞過WAF上傳文件
- 系統提權
- windows系統提權
- linux系統提權
- 數據庫提權操作系統
- 內網橫向滲透
- 內網穿透方式
- 一些內網第三方應用提權
- ARP與DOS
- ARP欺騙
- DOS與DDOS
- 一些DOS工具