在freebuf上看到了一個關於任意用戶重置密碼的系列文章，感覺挺不錯了，算得是上比較全得了，年初就看過，今天突然發現他出了新的文章，這里記錄一下。
原網址：http://www.freebuf.com/articles/web/160883.html。
之所以寫這篇文章主要是想總結一下這塊的問題，之前不夠體系，測試得時候有時候會忘記一兩點不測試，這次站在巨人身上總結下別人知識的同時加一些自己的想法和里面沒有的對象。這里沒有將實際的例子寫在這里，因為如果直接copy別人的例子來太那啥了，自己找例子工作量又很大，且對自己意義不大。所以如果各位有地方不大懂得可以去原地址看下實例，也可以直接留言問我。
一：重置憑證泄露
- 重置密碼時，憑證為發送到手機上的驗證碼，但是通過攔截發送發送驗證碼請求對應的response包時，發現驗證碼在response包中
- 重置密碼時，利用郵件找回密碼時，帶有憑證的重置鏈接泄露至客戶端（這是返回包中）
二：接受端可以修改
3.重置密碼時，憑證會發送到手機上，通過替換手機號，可以使用自己的手機號接受驗證碼
4.還有一種情況比較特殊，也是手機接受驗證碼，但是重置密碼的整個流程中並沒有輸入過手機號之類的，說明后台程序很可能是通過用戶名來查詢的電話號碼。整個重置流程中，一般第一步是綁定用戶名的地方，但是如果后面幾個流程中還會發送用戶名這個參數（這個時候發送的參數可能是單獨用於在數據庫中查詢手機號的，同時說明這個地方可能存在sql注入），可以修改嘗試一下。
三：
5.sessionid固定（也可以說是Cookie混淆），意思就是說不管使用那個用戶進行重置密碼操作，sessionid都是固定了，只是綁定的用戶不同（有時候只是用戶的登陸狀態不同，所以sessionid固定也會導致會話固定漏洞）。利用方法：使用攻擊者的賬號走重置密碼的流程，到最后一步也就是提交新密碼時不要點擊提交或者使用burp攔截請求包，再在同一瀏覽器中打開重置密碼的頁面，使用受攻擊者的賬號走流程，到走不動的時候如需要輸入手機驗證碼的時候，這時sessionid就已經和收攻擊者的賬號綁定在一起了。再將之前我們攔截的提交新密碼的請求放行，這時后台程序修改的將是受攻擊者賬號的密碼。
這里關於sessionid的知識 大家可以在網上查或者看我之前關於JWT的文章中有講，對於理解sessionid有很大的幫助。
5.還有一種情況比較簡單，就是使用攻擊者自己的賬號重置密碼走流程到最后一步提交新密碼時，使用burp抓包，如果請求包中包含有用戶名或id能信息，可以將其修改為受攻擊者的用戶名或密碼。（這個也屬於不安全對象直接引用的一種，原因是前面一大堆步驟都沒有實際意義，還是使用的最后一個請求中的用戶名或id進行的重置密碼操作）
7.有些重置密碼的時候，使用郵件接受的重置密碼的鏈接。有些程序使用RSET風格的請求，並將用於綁定用戶的信息（用戶名、id）直接或加密后放在鏈接中，那么我們只需將鏈接中這段信息對應地改成受攻擊者的信息即可。
四：重置憑證未校驗
8.服務器端未校驗token導致可以重置任意賬號密碼。這個我覺得還是很少見的應該，但是既然人家遇到了說明還是存在的。使用郵件接受到的重置密碼的鏈接如下：
http://www.xxx.net/users/retrievePasswordReset/key:xxxxxx/userEmail:lqs@qq.com
按道理，這里的key和useremail應該是一一對應的關系，但是如果應用程序有缺陷，key不起效果，我們可以使用找回admin的密碼，直接訪問構造的鏈接即可，key可以隨意填：
http://www.xxx.net/users/retrievePasswordReset/key:666666/userEmail:admin@qq.com
（我都不好意思繼續說下去，這樣的開發祭天吧）
9.有些重置密碼的模塊可以通過回答密保問題來重置密碼。但是有部分用戶並沒有設置密保問題，那么就有可能我們提交任意的密保答案都可以重置這些用戶的密碼。怎樣確認這些用戶是否存在密保呢？一般通過密保重置密碼的場景，第一步都會讓我們先輸入用戶名，發送請求包后我們可以攔截response包，很多時候，我們可以發現用戶存在且有密保、用戶存在但沒有密保、用戶不存在這三種情況返回包都不一樣，我們可以使用burp進行爆破找出存在但沒有密保用戶名。
五：憑證可以爆破
10.手機驗證碼為四位數，可以爆破
六：客戶端校驗返回包中的狀態碼
11.很多時候，比如說重置密碼最關鍵一步需要輸入手機接受的驗證碼，但是我們沒有正確的驗證碼，隨便輸入個1111，發送后攔截返回包，發現返回包中帶有參數，這個參數用於傳遞給前台以決定我們是否可以進入下一步。至於怎樣判斷這個參數是否是這個用處呢？其實很簡單，一般這種返回包中帶有的參數都很少，我們可以先使用攻擊者自己的賬號走一遍流程，輸入正確的手機驗證碼后，觀察參數值是什么，再走一次流程，故意輸入錯誤的驗證碼，觀察參數值是什么，然后兩種對比一下。比如說code=true/false或者是code=0/1或者是code=111/000這種，總之大家一看就清楚了。
七：token可預測
使用郵件接受重置密碼的鏈接時，一般都會帶有一個token用於判斷鏈接是否被修改過。如果token可以預測，那么攻擊者可以通過構造鏈接來重置任意的用戶密碼。
12基於時間戳生成的Token
部分程序使用當前時間戳MD5加密后的值作為token，那我們怎么知道具體的時間戳呢？可以使用我們自己的賬號先走一遍流程，再用admin的賬號走一次流程，再用自己的賬號再走一次流程。由於第一次和第三次是我們自己的賬號，可以收到郵件，我們取出兩郵件中重置密碼鏈接中的時間戳，那么admin的重置密碼鏈接中的時間戳應該時介於之前兩個時間戳之間的，使用burp爆破，找出正確的時間戳，構造鏈接即可。
13.基於遞增序號生成的token
多獲取幾次重置密碼的鏈接，發現參數具有一定的規律。比如說遞增。
14.基於關鍵字段生成的token
和上面的第一種情況類似，token可能並不是對時間戳進行的md5，也有可能時MD5(username+id)，例如這種。
八：邏輯漏洞
15.比如說重置密碼時，一般有四步，第三部是填手機驗證碼，第四步是填新密碼。我們進行到第三部時，直接繞過第三步，訪問第四步的url即可。至於怎樣知道第四步的url呢？使用自己的賬號走一遍流程不就可以了嗎。
九：host頭攻擊、sql注入、注冊admin或admin x、html注入和http leak什么的，不輸入邏輯漏洞
-------------------------------
測試的時候，一定要多重置幾次，看看憑證的變化