SRC漏洞挖掘過程中遇到登錄框時，總是感覺自己測試不完全，東一榔頭西一棒子，想起什么來測什么。
感覺這樣不太行，顯得不專業，於是乎總結一下，在以后的測試過程中可以作為筆記提示。
以下按照順序測試：
注冊頁面
- 注冊頁面批量注冊
- 注冊覆蓋（重復注冊他人賬號）
- 短信郵件炸彈
- 手機驗證碼是否可爆破（老生常談，Burpsuite抓包爆破四位驗證碼）
- 圖片驗證碼是否可繞過（驗證碼缺失、驗證碼失效數據包重放、萬能驗證碼0000、驗證碼空繞過、驗證碼前端獲取(極少數情況)）
登錄頁面
- 弱密碼、無驗證碼爆破、萬能密碼（后台登錄，用戶登錄次數限制）
- 手機驗證碼登錄是否可以進行短信炸彈
- url跳轉漏洞（主要用來釣魚，對於繞過和利用百度搜索已有大量文章，不贅述）
- 登錄處是否可繞過（對於大多數沒有cookie的網站）
- 用戶名枚舉（觀察返回包提示或者返回包參數變化）
忘記密碼
- 手機驗證碼是否可爆破
- 修改密碼流程是否可跳過
- 任意用戶密碼重置
- 短信郵件炸彈
這種網站注冊頁面，沒有手機短信驗證碼，那么，我們可以考慮，是否可以批量注冊呢？
對於批量注冊的前提是：該頁面處沒有圖形驗證碼或者圖形驗證碼失效！該頁面注冊處沒有圖形驗證碼。
注冊頁面雖然需要輸入姓名和身份證號，但是並未對姓名和身份證號去做核對，輸入任意的姓名和身份證號即可。
測試過程：注冊提交時Burpsuite抓包
先用正確的信息注冊，記住注冊成功時服務器返回的數據，知道注冊成功是返回什么
然后使用剛才的數據包遍歷修改手機號，賬號等參數發送，觀察回復的數據包狀態
對於注冊頁面覆蓋注冊是指原來用一個手機號已經注冊了賬號，但是由於漏洞，導致可以再利用該手機號進行注冊，並且會將之前注冊的記錄覆蓋！
當我們用已經注冊了的賬號准備再注冊時，發現會提示該手機號碼已經存在！
我們抓包，發現后端檢測該手機號已經注冊了的話，會返回 true。如果檢測該手機號沒注冊的話，會返回false。
修改回傳參數，達到重復注冊目的。
其實這就是個限流的問題——也就是限制某個接口的時間窗口內的請求數。
很多項目都少不了給用戶手機號或者郵箱賬號發短信郵件之類的，但是很多發送短信都是借助於第三方接口來發送短信的，這樣一來，發送的短信就是有限制的，收費的哦。如果系統做的不太好，有些小漏洞，被白帽子發現還好，要是被那些黑帽子發現了，少則幾千，嚴重者可能導致公司倒閉啊。即使不被黑帽子攻擊，有些惡意的用戶也可能系統進行破壞。
也可使用Burpsuite抓包爆破，西門吹雪大佬有過一個抓包給手機號后依次添加空格的實例
防范措施：
1. 限制每個手機號的每日發送次數，超過次數則拒發送，提示超過當日次數。
2. 每個ip限制最大限制次數。超過次數則拒發送，提示超過ip當日發送最大次數。
3. 限制每個手機號發送的時間間隔，比如兩分鍾，沒超過2分鍾，不允許發送，提示操作頻繁。
4. 發送短信增加圖片驗證碼，服務端和輸入驗證碼對比，不一致則拒絕發送。
不可靠的前端校驗
還是會有許多的網站他們沒有嚴格進行身份校驗，他們往往是通過依靠帳號密碼登陸后發送后回傳的JSON數據來判斷用戶身份是否正確，這就暴露出了很大的漏洞，這種漏洞利用起來就相當的容易，往往只需要一個安全界的神器 BURP 就可以完成身份驗證的繞過，在登錄的時候輸入正確的賬戶以及隨意的密碼，將報文攔截下來，然后選擇 burp 里面的攔截返回包的功能，捕捉返回的狀態碼。
幾乎所有需要登錄的網站都有一個忘記密碼然后重置密碼的功能，如果網站在密碼重置功能處的代碼不夠嚴謹，將可能造成任意密碼重置的邏輯漏洞。
1、 驗證碼失效，導致攻擊者可以通過爆破其他用戶手機驗證碼來實現任意用戶密碼重置
·2、驗證碼未綁定用戶：也就是我們可以利用自己的手機號來進行成功驗證手機驗證碼，然而在提交修改密碼處提交其他人的手機號，來實現修改其他人的密碼
·3、修改接收驗證碼的手機或郵箱：當我們修改密碼時，輸入正確的用戶名，點擊發送驗證碼，抓包，發現數據包中有該用戶名對應的手機或者郵箱，我們將其修改為自己的手機或郵箱來接收驗證碼。輸入我們收到的驗證碼，即可實現對該用戶的密碼進行重置。(這里還存在一個信息泄露，即知道用戶名就能知道該用戶對於的手機或郵箱)
·4、跳過驗證步驟：網站對修改密碼的步驟，沒有做校驗，導致可以直接輸入最終修改密碼的鏈接，直接跳轉到該頁面，然后輸入新密碼達到重置密碼的目的。首先使用我們自己的賬號走一次流程，獲取每個步驟的頁面鏈接，然后記錄頁面3對應的輸入新密碼的鏈接，重置他人用戶時，獲取驗證碼后，直接輸入密碼修改頁面鏈接到新密碼的界面，輸入密碼重置成功。
5、 cookie值的替換：重置密碼走到最后一步的時候僅判斷唯一的用戶標識cookie，並沒有判斷該cookie有沒有通過之前重置密碼過程的驗證，導致可替換cookie重置他人用戶密碼。重置自己用戶密碼到達最后階段，抓到數據包，並在第一階段重新獲取其他用戶cookie，替換cookie到我們抓取的數據包中，發包測試。