【轉載】任意用戶密碼重置的10種常見姿式

【原文連接】https://www.lovesec.com/penetration-test/233.html

1 驗證碼不失效

• 形成緣由：找回密碼的時候獲取的驗

證碼缺乏時間限制僅值判斷了驗證碼是
夠正確未判斷驗證碼是否過時

• 測試方法：經過枚舉找到真正的驗證

碼輸入驗證碼完成驗證
-案例
輸入目標手機號，獲取驗證碼隨意輸入驗證碼1234點擊下一步，攔截數據包

POST /Account/CheckYQCode HTTP/1.1 Host: www.xxxx.cn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Accept: */* Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest http://www.xxxx.cn/userCenter/toForgetPsdPage.html?mobile= Content-Length: 11 Cookie: ASP.NET_SessionId=30jfruwn22h2xng3ahhzo2jx Connection: close YQCode=1234

獲得正確的驗證碼是1059而後到網站上輸入驗證碼跳轉到輸入新密碼的頁面完成重置密碼

2驗證碼直接返回

• 1.輸入目標手機號，

點擊獲取驗證碼

• 2.驗證碼直接返回

1269，輸入驗證
碼跳轉到重置頁面

3.驗證碼未綁定用戶

• 形成緣由：輸入手機號和驗證碼進行重置密碼的時候，僅對驗證碼是夠正確進行了判斷，未對該驗證碼是否與手機號匹配作驗證。
• 測試方法：在提交手機號和驗證碼的時候，替換手機號爲他人手機號進行測試，成功經過驗證並重置他人密碼。

首先使用本身的手機號接收驗證碼而後輸入本身手機號接收到的驗證碼，點擊下一步並攔截數據包最後替換數據包裏的目標手機號，而後發包

這個案例也是驗證碼未綁定用戶延伸一下，有時候測試會碰到這種，咱們發現用戶名被加密了，咱們又沒法得知加密算法，怎麼辦？大部分這種都不須要知道加密算法，好比這個例子，獲得的liuyy的加密後的值是80e688602c4b11e66320c421e3b71ef2，那麼咱們就能夠直接用這個keycode了

步驟是同樣的，輸入咱們的用戶名和收到的驗證碼，而後把咱們的keycode替換爲liuyy的那個keycode，這樣就能夠重置liuyy的密碼了。（漏洞緣由仍是是判斷了驗證碼是否正確，而沒有判斷該驗證碼是否跟該用戶匹配。）

4.修改接收的手機或郵箱

• 形成緣由：用戶名、手機號、驗證碼三者沒有統一進行驗證，僅判斷了三者中的手機號和驗證是否匹配和正確，若是正確則判斷成功並進入下一流程。
• 測試方法：輸入用戶名獲取驗證碼，修改接收驗證碼的手機號爲本身的號碼，本身手機成功接收驗證碼，提交到網站進行驗證，驗證成功並進入下一流程。

點擊找回密碼，首先咱們輸入zhangwei，而後點擊獲取驗證碼，這個時候把手機號改成咱們本身的號碼，輸入咱們本身的號碼和驗證碼，成功跳到重置密碼的頁面，密碼重置成功

5本地驗證的繞過

• 形成緣由：客戶端在本地進行驗證碼是否正確的判斷，而該判斷結果也能夠在本地修改，最終致使欺騙客戶端，誤覺得咱們已經輸入了正確的驗證碼。
• 測試方法：重置目標用戶，輸入錯誤驗證碼，修改返回包，把錯誤改成正確，便可繞過驗證步驟，最終重置用戶密碼。

輸入手機號13888888888，輸入驗證碼123456，驗證碼錯誤的時候，返回包返回的是0

這裏咱們所作的就是把0修改成1，能夠借工具修改返回包，咱們把0改成1，而後查看頁面，成功跳轉到修改密碼的頁面，輸入新密碼便可修改用戶13888888888的密碼

6跳過驗證步驟

• 形成緣由：對修改密碼的步驟，沒有作校驗，致使能夠直接輸入最終修改密碼的網址，直接跳轉到該頁面，而後輸入新密碼達到重置密碼的目的。
• 測試方法：首先使用本身的帳號走一次流程，獲取每一個步驟的頁面連接，而後記錄頁面3對應的輸入新密碼的連接，重置他人用戶時，獲取驗證碼後，直接輸入頁面3連接到新密碼的界面，輸入密碼重置成功。

使用帳戶wangshuai，點擊獲取驗證碼，而後補齊下面的連接https://xxx/page/login/veifyAccess.html?username=wangshuai&email=wangshuai@xxx.com.cn，訪問後便可直接重置該用戶的密碼

7未校驗用戶字段的值

• 形成緣由：在整個重置密碼的流程中，只對驗證碼和手機號作了校驗，未對後面設置新密碼的用戶身份作判斷，致使在最後一步經過修改用戶身份來重置他人的密碼。
• 測試方法：使用本身的手機號走流程，在走到最後一個設置密碼的流程時，修改數據包裏的用戶信息。

8修改密碼處id可替換

• 形成緣由：修改密碼的時候，沒有對原密碼進行判斷，且根據id的值來修改用戶的密碼，相似的SQL語句：update user set password="qwer1234" where id = ‘1’修改數據包裏的id的值，便可修改他人密碼。
• 測試方法：修改本身用戶密碼，抓取數據包，替換數據包中用戶對應的id值，便可修改他人的密碼。

點擊當即提交，獲得右邊的數據包，測試發現修改id爲5，就能夠把對應的用戶密碼修改成123456，沒有對用戶的原始密碼判斷，也沒有判斷id是否屬於該用戶。8.修改密碼處id可替換

成功修改id爲5的用戶密碼爲123456，並且能夠經過遍歷id修改全部用戶的密碼

9.cookie值的替換

• 形成緣由：重置密碼走到最後一步的時候僅判斷惟一的用戶標識cookie是否存在，並無判斷該cookie有沒有經過以前重置密碼過程的驗證，致使可替換cookie重置他人用戶密碼。（cookie可指定用戶獲取）
• 測試方法：重置本身用戶密碼到達最後階段，抓到數據包，並在第一階段從新獲取目標用戶cookie，替換cookie到咱們抓取的數據包中，發包測試。

到第一步去獲取驗證碼的時候，點擊下一頁，能夠獲取到該用戶wangshuai對應的內容Cookie: JSESSIONID=E1AC27A7302C03C9432DE2254B99311A

10.修改信息時替換字段值

• 形成緣由：在執行修改信息的sql語句的時候，用戶的密碼也看成字段執行了，並且是根據隱藏參數loginid來執行的，這樣就致使修改隱藏參數loginid的值，就能夠修改他人的用戶密碼。
• 測試方法：修改我的資料的時候，抓取數據包，而後來修改數據包的參數和對應的值，參數名通常能夠在其餘地方找到，替換隱藏參數便可修改他人的密碼等信息。

view-source:https://www.xxx.com/ua/employee/forUpdate.do查看下這個頁面的源代碼，找到了一個參數loginId，這個參數是對應用戶身份的而咱們發現 上面的數據包裏沒有這個參數，那麼咱們是否能夠本身添加上去呢？

添加字段loginId，而且把值修改成他人的用戶，發包返回修改爲功這樣咱們就成功的把用戶871XXXXXX的密碼改成了跟咱們密碼相同的值