记一次有趣的密码重置

来自:FreeBuf.COM

最近被客户日的头晕晕,不但要搞定客户,还要搞定他们的开发,在熬掉14根头发后发现了这个漏洞,觉得比较有意思。

前景提要

之前有测过客户的App,发现在忘记密码的地方存在手机号验证绕过导致任意用户密码重置,登陆后的修改密码也是存在手机号验证绕过问题。这次测试的是Web端,发现之前的几个接口都是和app一样的,所以拿到手就先开始对密码这部分下手。

正片

开局直奔忘记密码的重置,但是开发已经学乖了,已经把这个在app端发现的问题修复了,寻之无果,又转战到个人中心修改密码处。

image.png

看起来是挺吓人的,又是手机验证码,又是旧密码的。走一波流程,发现是先验证手机验证码,从下图的参数中可以看到是分步验证的,首先尝试绕过手机验证。

image.png

image.png

修改code=0绕过第一次手机号验证。下图为第二次验证提交参数,发现还有一个验证码的参数,以为会进行二次效验,但是万万没想到,直接放行就修改成功了。。。。。。

image.png

image.png

看来都是纸老虎,再看参数中好像并没有其他做验证的参数,丢到repeater里尝试看看修改手机号为另一个手机号能否成功。

image.png

???黑人问号脸,看来还是做了身份验证,也就是上图中的ut值,绑定当前用户的手机号,也就是说要修改别人手机号得拿到别人的ut值。原本打算到这里结束了,但是心有不甘,回想了一下上一次挖到的任意用户密码重置过程,在上一次的挖掘中重置用户密码是没有用户身份验证的,因为是从忘记密码进去的,所以没有经过用户登录,然而登录以后则验证了ut和手机号。那么问题就在于如何让他变成没有用户登录的情况,由于ut值是整个系统判断用户登录信息的唯一参数,所以我尝试删除cookie中的ut值,达到用户未登录状态。

image.png

Bingo,大吉大利,今晚吃鸡。

观后感

初步猜测一下这个逻辑是存在ut值的时候会对当前用户的手机号进行验证,然而在没有ut值的时候无法获取当前用户信息,也就无法进行手机号验证,同时也未对手机验证码以及旧密码进行验证导致密码修改成功。

推荐↓↓↓
黑客技术与网络安全
上一篇:为什么那么多人用“ji32k7au4a83”作密码? 下一篇:安全行业找工作,单位、团队组建,HR有哪些问题?