前記

• 今天是學習小迪安全的第七十四天，本節課主要內容是關于驗證碼機制的，常見的三種驗證方式就是手機驗證碼、短信驗證碼、短信驗證鏈接，這里講了如何去嘗試繞過他們的幾種方法
• 主要以理解繞過思路為主，當然也需要下去自己復現理解思路邏輯
• 所需要的靶場資源已放至下方鏈接，需要自取：
  • https://pan.baidu.com/s/1YSjyW4ehxfDrqeeWjEXsSA
  • 提取碼：gaii

WEB攻防——第七十四天

機制驗證篇&重定向發送&響應狀態碼&跳過步驟&驗證碼回傳&枚舉

驗證碼突破 - 回傳顯示&規律爆破

漏洞原理

• 回傳顯示這個完全是屬于開發者設計失誤，將驗證碼回顯到數據包中，導致攻擊者能夠直接得到驗證碼，繞過
• 而規律爆破這里，主要是驗證碼校驗時位數有限或者規律可知，并且驗證碼存活時間長、沒有提交次數限制，導致攻擊者可以通過爆破枚舉的方式繞過

案例演示

回傳顯示

• 這里之前碰到過一個真實案例，直接將驗證碼回顯到數據包中，能夠直接繞過：
  

• 但是現在這種例子應該比較少了，gay迪上面演示的例子應該也是很早之前的例子了

• 首先找到發送驗證碼的頁面，然后抓包：
  
  

• 發現驗證碼就直接回顯在數據包中，那這時就直接繞過了

• 或者有些不是直接回顯，而是你輸入錯誤的驗證碼，服務器回顯正確的驗證碼：
  

• 反正都可以測，這種漏洞也是越來越少了

規律爆破

• 這里福利期貨APP應該是沒了，不知道為什么我這邊模擬器打不開，那我們就理解這個思想就好了

• 其實就是響應包中附帶自己提交的驗證碼值，然后利用BP去爆破：
  

• 看哪個成功就直接用，不過現在都是6位驗證碼，而且規定了時間，所以基本是很難爆破了

驗證目標 - 重定向發送&重定向用戶

漏洞原理

• 重定向發送就是嘗試將本來發送給別人的驗證碼發送到我們自己這里，造成繞過
• 重定向用戶就是我們自己接收驗證碼，然后提交時將用戶換成目標用戶，造成繞過
• 核心都是嘗試將驗證碼發送給我們自己，只不過更改的步驟不同，相當于正常接收驗證碼的步驟是：

用戶填入正確電話/郵箱 -->  發送驗證碼  -->  接收驗證碼  -->  進入下一步操作

• 重定向發送是在第一步到第二步之間，而重定向用戶是在第三步到第四步之間

案例演示

重定向發送

• 這里演示的案例是MetInfo，搭建環境為PHP5.4，MySQL5.7，搭建教程略過

• 我們需要先配置一下郵箱設置，登錄到后臺，然后點擊設置，找到郵件發送設置，填入相應的信息：
  

• 注意密碼填入的是郵箱的授權碼，不知道怎么獲取授權碼的可以上網查一查，這里我用的是163郵箱，然后是在這里獲取的授權碼：
  

• 好，我們退出登錄重新來到后臺登錄頁面，選擇忘記密碼，使用電子郵箱找回，然后輸入自己用戶名或電子郵箱：
  

• 點擊下一步抓包：
  

• 這里是有一個met_host參數可以傳入的，他可以將服務器發送數據包的地址修改為自己的，如 nc 監聽的一個端口

• 這里在自己的服務器上開啟監聽，然后發包，按道理來說是能夠成功的，但是我本地是沒有復現成功，如果成功接收是這樣：
  

• 然后點擊鏈接就可以重置別人的密碼了

• 這里給我們的啟示就是如果數據包中出現這樣的參數，我們可以嘗試修改為自己，讓他的流量經過我們本地

重定向用戶

• 這里演示案例是EyouCMS，搭建環境為PHP7.3，MySQL5.7，搭建教程就略過了

• 然后我們配置一下電子郵件，登錄到后臺，然后選擇接口配置，找到電子郵件配置，同樣填入相應的信息即可：
  

• 配置好之后，我們先注冊兩個用戶：

+ 用戶A:用戶名: test01密碼: test01郵箱: test01@qq.com (這里換成你的真實郵箱)+ 用戶B:用戶名: test02密碼: test02郵箱: test02@qq.com (這里換成你的真實郵箱)

• 然后我們通過找回密碼處，嘗試找回test01的密碼：
  

• 這里我們可以嘗試抓包看看：
  

• 我們嘗試將email的值修改為test02的郵箱，發包：
  

• 然后我們就成功進入test02用戶的重置密碼界面：
  

• 這里能不能修改成功只用試一下就好了，這里就不繼續演示了

• 這就是重定向用戶，其實他的原理就是通過郵箱去綁定了用戶，并且沒有做驗證碼與當前郵箱綁定的判斷，導致任何郵箱都可以利用當前的驗證碼繞過，造成漏洞

驗證邏輯 - 修改響應包&跳過步驟URL

漏洞原理

• 修改響應包主要是因為網站采用的是前端驗證的方式，我們可以通過攔截服務器的響應包，將其修改為正確的返回值，嘗試繞過驗證碼驗證
• 而URL跳過步驟則是我如果能夠完整的抓到比如忘記密碼步驟的包，那么可以嘗試直接跳到最后一步繞過驗證碼
• 修改響應包是針對于驗證在前端的
  1. 通過手機找回密碼一般需要短信驗證碼驗證，服務端需要告訴客戶端，輸入的驗證碼是否正確，如果客戶端收到 true 的信息，那么就會向帶著 true 的信息向服務端請求進入下一步，而服務端收到 true 的信息，就會允許客戶端進入下一步，反之，如果是 false 的信息，服務端就不會允許客戶端進入下一步。也就是說我們進入下一步的關鍵是讓服務端收到客戶端的 true 信息，而借助 burpsuite，我們可以修改服務端返回到客戶端的信息，這樣一來，我們就可以輸入任意短信驗證碼，然后將服務端返回的 false 信息改為 true 就可以繞過短信驗證碼的驗證了。
  2. 找回密碼流程一般需要四個步驟：
     • 流程：驗證用戶名 - 驗證短信驗證碼 - 輸入新密碼 - 重置成功
     • 這四個步驟應該緊緊相連，互相相關，只有通過了第一個步驟驗證才可以進入下一個步驟，如果每個步驟之間沒有進行關聯性驗證，就可能導致跳過關鍵驗證步驟，從而導致重置任意賬號密碼。

• 實戰中先每個流程正確的數據包以及響應包抓取下來，然后進行后續測試

案例演示

• 這里那個福利期貨演示不了，沒辦法打開，只能說是看視頻然后了解有這種測試思路即可
• 其實很簡單，基本就是先測試一遍正確的流程，然后再對響應包進行修改，看能不能嘗試繞過

實戰SRC案例分享

• 這里同樣來看看實戰中的SRC漏洞的挖掘，學習一下測試思路

短信驗證碼回傳顯示

• 這里就是上面說過的，不再演示

修改用戶對象重置任意用戶

• 這里就是忘記密碼的時候抓包，發現他有一個userid的參數，我們可以嘗試修改該參數為他的前一位id
• 為什么是前一位呢，因為如果他是遞增的id值，那么后面的id可能就沒有被注冊過，也就沒什么用
• 然后這里修改之后發現能夠成功重置其他用戶的信息

修改響應包重置任意用戶

• 還是一樣到重置密碼功能處，發送驗證碼然后抓包：
  

• 我們這里可以測試重定向，或者抓取服務器的響應包看看：
  

• 發現他的回顯為false，并且提示驗證碼錯誤，那我們是不是可以猜測返回值為true或者success這些就說明驗證碼正確呢

• 于是修改響應包中的返回值為true，然后放包，發現他提示驗證碼正確，并成功進入重置密碼頁面：
  
  

未驗證導致重置任意用戶

• 這里就是開發者在驗證的時候沒有判斷當前id和驗證碼信息是否綁定，導致攻擊者可以通過修改參數r為其他的用戶id，就能夠重置其密碼
  

總結

• 所以總的來說，其實就是看參數，然后修改再修改，看看開發者有沒有存在邏輯上的紕漏