这是一个我去年在公司内部分享的案列。

系统登录是双因子认证登录，找回密码时验证账户和手机号以及手机验证码。一般来说，这种认证方式不会存在登录隐患，但这里逻辑处理存在缺陷导致任意重置。

一、各页面逻辑功能情况。

1、登录页面处理逻辑

首先来看一下系统登录的处理页面

通过前端页面不难发现，进入系统需要对应账号密码以及短信验证码；经过实际测试，登录的时候校验了用户密码是否正确、短信验证码是否正确。

2、注册页面

看到有一个注册页面，尝试注册账号，可惜需要审核，注册页面pass。

3、忘记密码页面

那看看忘记密码的逻辑

从页面来看需要账户，手机号，手机号验证码。

我们输入任意账号，返回账号不存在

走到这里，当前的思路当然是用字典枚举一下；实际是没有出货。后面通过注册页面发现存在账户123，但是当前页面输入该账户也返回账号不存在。

查看密码复杂度要求，10位的复杂密码。

二、登录绕过尝试

登录最常用的就是看返回包，我们抓登录返回包进行修改，尝试登录绕过。
然后输入对应账号进行抓包测试，修改第一个包返回：当前用户已登录；

此时是心头一喜，感觉进去了。

然而现实是残酷的，点击强制登录，会发现再次校验了用户名和密码，然而拦截对应返回包不再是校验，而是html了，无法控制返回包。

结果就是用户或密码错误

然后总结一下：
当前系统双因子登录的手机验证码是可以绕过，但是密码不行；联想到的就是，只要我们知道某个账号的密码或者能实现任意重置，我们就可以登录系统。
找到一个可以用的账号密码还是比较难，那我们尝试密码重置，毕竟验证码可以绕过。

三、密码重置

输入我们已知账号
然后再输入一个任意手机号，任意验证码以及符号要求的密码，点击提交抓包。

拦截对应返回包，会进行多次校验
第一个返回包是no-user，显示不存在该用户。但是我们通过注册接口确认存在该用户，再结合注册时相关成功结果的返回包，我们修改返回结果为1

之后遇到第二个数据包校验，增加了一个手机号

同样拦截返回包，修改其结果为1

然后第三个数据包，我们看到带上了用户名，手机号，验证码以及密码；注意，这是第一次带上验证码，应该就是对验证码的校验。同样拦截返回包，进行查看分析。

果然返回包的结果为0，应该就是验证码校验了，修改0为1

然后就是第四个数据包，post请求，带上了所有相关数据信息，不管这个是什么的校验，拦截返回包分析一下。

发现是一个success的跳转，对应下一个包是一个success的连接

然后前端返回成功的提示，并跳转到登录界面。

到此，我们猜测可能已经完成对账号123的密码重置，但没有登录验证，具体结果不得而知，也许我们被前端状态欺骗了也说不定。

四、登录验证

输入账号密码，任意验证码抓包，拦截第二个包，也就是验证码的返回包，修改返回的0为1

之后又出现了一个包，传递数据是账号；这个一样的拦截他。

之后又到了强制登录页面，这次点击登录一样的出现一个用户名密码的包

由于账号密码登录的返回包是html，不用分析了。直接放通，幸运的是密码重置成功，然后成功进入系统后台。

五、总结

第一次挖到这种类型的重置，所以自己的文库有这么一个记录，最近打算总结一下所有的逻辑相关漏洞，再次打开了这个文章进行整理。
系统缺陷：
短信验证码可被绕过；
手机号与对应账号未进行绑定，从开始到最后，我始终用的任意测试手机号。
本来根据前端页面的结构来说，想要登录系统或者重置密码是比较艰难的。但是这两个逻辑错误的结合就直接导致任意用户密码重置，并登录后台。