登錄註冊表單滲透
- 2020 年 3 月 9 日
- 筆記
大家在甲方授權的滲透測試中，經常會遇到各種表單：登錄、註冊、密碼修改、密碼找回等表單，本技術稿着重介紹關於各種表單的滲透經驗，拋磚引玉，歡迎大家交流互動。
方便大家查看，製作如下思維導圖，以下只詳細介紹其中一些重要常用的漏洞。
一、登錄處是否可繞過—>（抓包decode+爆破）【高危】
password在前端用url編碼—>URL Decode
爆破成功
漏洞修復：
1、增強驗證碼機制，為防止驗證碼被破解，可以適當增加驗證碼生成的強度，例如中文圖形驗證碼。 2、用戶名或密碼輸入錯誤均提示「用戶名或密碼錯誤」，防止黑客獲取到註冊用戶信息。 3、限制用戶登錄失敗次數。 4、限制一定時間內IP登錄失敗次數。 5、使用雙因子驗證策略
二、賬號/密碼可枚舉 [高危]
漏洞描述:由於頁面對輸入的賬號、密碼判斷的回顯不一樣，攻擊者可以通過回顯差異進行用戶名的枚舉，拿到賬戶名來進行弱口令的爆破。
用戶名存在
用戶名不存在
漏洞修復：
1.增加驗證機制，如驗證碼 2.添加token 3.統一身份驗證失敗時的響應，用戶名或密碼錯誤
三、賬號/密碼硬編碼【高危】
漏洞描述：賬號或密碼都被硬編碼在頁面中，只需要輸入正確用戶名/密碼/驗證碼即可
漏洞修復：
1.取消默認硬編碼配置，刪除敏感信息，禁止直接明文存儲在前端登陸框。
四、手機驗證碼可爆破
前提：該頁面沒有圖形驗證碼或圖像驗證碼失效+後端對驗證碼輸入錯誤次數沒有做任何限制+驗證碼的時效性高於爆破時間.
爆破成功
漏洞修復：
1.點擊獲取手機驗證碼後產生即時更新強圖形驗證碼 2.限制輸入錯誤次數 3.縮短驗證碼的有效期
五、短訊轟炸
修改號碼回顯為ok
現在可以寫個小程序對目標進行循環發包，實現短訊轟炸
Note：為了防止被ban，給大家說個技巧：可以停頓十秒再發下一個；有時雖然後端對其進行驗證，但是還是有辦法繞過 1>刪除cookie值 2>手機號後加空格或n
漏洞修復：
1.後端對同一手機號在某段時間只能發送一條短訊，並且設置發送次數的上限
六、註冊表單之批量註冊
正確的信息註冊 response：{"content":"/User","type":1,"data":null}
對手機號進行批量遍歷，發現批量成功，存在批量註冊漏洞
七、註冊表單之覆蓋註冊
漏洞詳情：此漏洞是指以前已經用一個手機註冊了會員，由於此漏洞的存在，導致可以利用該手機號重複註冊，並且會覆蓋之前註冊的會員信息。
已註冊：顯示ture,沒註冊：顯示false
修改返回包為false
發現此手機號又可以註冊了！
八、任意用戶密碼重置
漏洞描述：在修改密碼錶單處 通過修改數據包的特定數據修改任意用戶的密碼
修改id為需要重置的用戶
id 10016的密碼重置為123456
漏洞修復：
1. 使用session對當前用戶的權限做校驗 還有以下情況我就不一一舉例了。 1>Cookie值替換 2>跳過驗證步驟 3>驗證碼未綁定用戶
九、圖形驗證碼繞過（從代碼層面分析）
原理解讀：
驗證碼(CAPTCHA)Completely Automated Public Turing test to tell Computers and Humans Apar —>全自動人機區分的圖靈測試。
圖形驗證碼應用非常廣泛，無論在Web應用還是客戶端軟件，為防止暴力破解、機器註冊等。遺憾的是好多開發者不得要領，為完成工作進度，敷衍了事。
驗證碼常見的安全問題： 1>驗證碼存在邏輯缺陷，可被繞過，可被逆向； 2>驗證碼太簡單，容易被機器識別;
Q1：把驗證碼是否出現的判斷邏輯放在客戶端瀏覽器
原理：某些系統默認不顯示驗證碼，只有在用戶校驗錯誤一定次數之後再出現。
那我非常好奇，那如何判斷用戶已經錯誤幾次了呢？沒有經驗的開發可能這樣做：
1.在cookie中寫入一個標記，Eg:loginErr = 1，後續錯誤累加. 2.在session中寫入一個標記，Eg:loginErr = 1，後續錯誤累加.
問題來了，如果攻擊者不帶Cookie提交HTTP請求呢？或攻擊者不更新Cookie中的loginErr的值反覆提交呢？
程序因為無從獲取Cookie/sessionID，會認為攻擊者是首次訪問，無論什麼時候，驗證碼都不會出現！
Q2：驗證碼不過期，單個驗證碼反覆可用
原理：大部分情況，驗證碼在web服務器上對應一個session值。如果完成一次校驗，不標記這個session已失效，就會造成同一驗證碼反覆可用，因此攻擊者在cookie中帶固定的sessionID和固定的一個驗證碼字符串，即可輕鬆爆破。
還有一種非常常見的代碼實現思路，更新session的工作是通過重新下載驗證碼達到的，開發人員最容易犯的一個失誤就是把更新session的任務交給客戶端瀏覽器來完成。Eg:302重定向，甚至是通過js、meta refresh重定向頁面，來引導用戶重新下載驗證碼。這些做法實際是錯誤的，要是用戶攔截了重定向，沒有發出新的下載請求呢？上次的驗證碼是否還可以使用?開發者需要做到：一張驗證碼，只能使用一次。使用之後，立即過期，不可再次使用！
Q3 將驗證碼內容輸出到客戶端
不管出於什麼考慮，都不應該把驗證碼的內容發送到客戶端cookie、或輸出到response headers的其他字段。Eg:寫入驗證碼的MD5值、 Base64轉碼等，太容易被黑客逆向破解，得到原值了，即便是加固定salt後輸出，都是不安全的。
Q4 驗證碼太弱
通常出現邏輯錯誤的驗證碼，同樣存在太弱的通病，使用開源的tessertact OCR引擎，不經任何訓練，不人工去噪處理，能識別互聯網上的大部分驗證碼！
實例演示： 驗證碼重放攻擊
漏洞詳情:測試發現，在用戶登錄時，驗證碼不是即時刷新，導致攻擊者可通過重放驗證碼進行登錄爆破。
抓包發現驗證碼數據並沒有傳輸到後端校驗
漏洞修復：
1.驗證碼只能用一次，用完立即過期！不能再次使用,實現一次一碼。 2.驗證碼不要太弱。使用扭曲、變形、干擾線條、干擾背景色、變換字體等。 3.大網站最好統一安全驗證碼，各處使用同一個驗證碼接口。
*本文原創作者：星空111，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載
