最近被客户日的头晕晕，不但要搞定客户，还要搞定他们的开发，在熬掉14根头发后发现了这个漏洞，觉得比较有意思。
前景提要
之前有测过客户的App，发现在忘记密码的地方存在手机号验证绕过导致任意用户密码重置,登陆后的修改密码也是存在手机号验证绕过问题。这次测试的是Web端，发现之前的几个接口都是和app一样的，所以拿到手就先开始对密码这部分下手。
正片
开局直奔忘记密码的重置，但是开发已经学乖了，已经把这个在app端发现的问题修复了，寻之无果，又转战到个人中心修改密码处。
看起来是挺吓人的，又是手机验证码，又是旧密码的。走一波流程，发现是先验证手机验证码，从下图的参数中可以看到是分步验证的，首先尝试绕过手机验证。
修改code=0绕过第一次手机号验证。下图为第二次验证提交参数，发现还有一个验证码的参数，以为会进行二次效验，但是万万没想到，直接放行就修改成功了。。。。。。
看来都是纸老虎，再看参数中好像并没有其他做验证的参数，丢到repeater里尝试看看修改手机号为另一个手机号能否成功。
？？？黑人问号脸，看来还是做了身份验证，也就是上图中的ut值，绑定当前用户的手机号，也就是说要修改别人手机号得拿到别人的ut值。原本打算到这里结束了，但是心有不甘，回想了一下上一次挖到的任意用户密码重置过程，在上一次的挖掘中重置用户密码是没有用户身份验证的，因为是从忘记密码进去的，所以没有经过用户登录，然而登录以后则验证了ut和手机号。那么问题就在于如何让他变成没有用户登录的情况，由于ut值是整个系统判断用户登录信息的唯一参数，所以我尝试删除cookie中的ut值，达到用户未登录状态。
Bingo，大吉大利，今晚吃鸡。
观后感
初步猜测一下这个逻辑是存在ut值的时候会对当前用户的手机号进行验证，然而在没有ut值的时候无法获取当前用户信息，也就无法进行手机号验证，同时也未对手机验证码以及旧密码进行验证导致密码修改成功。
*本文作者：Strjziny，转自FreeBuf