知識星球作者：Strjziny，來自FreeBuf.COM
最近被客戶日的頭暈暈，不但要搞定客戶，還要搞定他們的開發，在熬掉14根頭髮後發現了這個漏洞，覺得比較有意思。
前景提要
之前有測過客戶的App，發現在忘記密碼的地方存在手機號驗證繞過導致任意使用者密碼重置,登陸後的修改密碼也是存在手機號驗證繞過問題。這次測試的是Web端，發現之前的幾個介面都是和app一樣的，所以拿到手就先開始對密碼這部分下手。
正片
開局直奔忘記密碼的重置，但是開發已經學乖了，已經把這個在app端發現的問題修複了，尋之無果，又轉戰到個人中心修改密碼處。
看起來是挺嚇人的，又是手機驗證碼，又是舊密碼的。走一波流程，發現是先驗證手機驗證碼，從下圖的引數中可以看到是分步驗證的，首先嘗試繞過手機驗證。
修改code=0繞過第一次手機號驗證。下圖為第二次驗證提交引數，發現還有一個驗證碼的引數，以為會進行二次效驗，但是萬萬沒想到，直接放行就修改成功了。。。。。。
看來都是紙老虎，再看引數中好像並沒有其他做驗證的引數，丟到repeater裡嘗試看看修改手機號為另一個手機號能否成功。
？？？黑人問號臉，看來還是做了身份驗證，也就是上圖中的ut值，系結當前使用者的手機號，也就是說要修改別人手機號得拿到別人的ut值。原本打算到這裡結束了，但是心有不甘，回想了一下上一次挖到的任意使用者密碼重置過程，在上一次的挖掘中重置使用者密碼是沒有使用者身份驗證的，因為是從忘記密碼進去的，所以沒有經過使用者登入，然而登入以後則驗證了ut和手機號。那麼問題就在於如何讓他變成沒有使用者登入的情況，由於ut值是整個系統判斷使用者登入資訊的唯一引數，所以我嘗試刪除cookie中的ut值，達到使用者未登入狀態。
Bingo，大吉大利，今晚吃雞。
觀後感
初步猜測一下這個邏輯是存在ut值的時候會對當前使用者的手機號進行驗證，然而在沒有ut值的時候無法獲取當前使用者資訊，也就無法進行手機號驗證，同時也未對手機驗證碼以及舊密碼進行驗證導緻密碼修改成功。
