在某次挖掘漏洞练手的过程中，碰到过一个比较特别的逻辑漏洞。之所以说比较特别是因为漏洞是偶然之间触发的，并且我本人在漏洞触发之后也是花了快半小时才理清这个逻辑漏洞要怎么复现。

直接来到漏洞页面，如下图。

前期信息收集的时候找了不少学号，可以直接开始测试。这里找回密码的时候后端会自己根据你输入的用户账号查询对应的账号是否存在。
输入账号和验证码，跳转到下图。

这里当时提交漏洞的时候没有注意存图，大概说一下这里的校验流程。
首先这里可以随便输入一个验证码，然后抓响应包修改(就是把响应包中的fail改成success)进入下一步密码重置页面。当然密码重置的时候会失败，因为校验了短信验证码的结果。

然后这里还校验了一下用户是否发送了验证码。如果没有点击发送验证码就提交验证码，会返回验证码未发送的提示。如果发送了验证码会提示验证码错误。

漏洞挖掘的时候，自己第一次成功触发是在验证码处输入了null，然后成功第一次重置了某个同学的密码，如图

其实当时我自己是非常懵的，感觉有点莫名奇妙。
回想一下密码重置的校验过程
输入账号--》校验是否发送验证码--》校验验证码是否正确--》密码重置成功
当时测试了半个多小时吧，最终成功复现。

先讲一下如何完整复现这个密码找回的逻辑漏洞，再猜想为何有这种行为。

第一步
输入用户账号和验证码

第二步
点击发送短信验证码

成功获取验证码后可以看到提示信息

第三步
此时再度点击，通过手机号找回密码

第四步
重新输入刚才的账号(注意这里必须是同一个账号才行)，验证码

第五步
直接来到了刚才的短信验证码界面，但是这次不需要发短信了，直接输入null，提交

第六步
来到密码重置界面，直接设置密码就可以重置了

登录验证下。没问题

根据漏洞挖掘的过程
猜想这个逻辑漏洞后端应该有如下逻辑。
有一个校验短信验证码的字段，这里暂且叫send_flag 默认应该为false，发送短信后被设置为true。
这里能成功重置用户密码的关键也在于存在一个默认的短信验证码null。
根据逻辑漏洞的行为可以大胆猜想每次用户点击通过手机找回密码后，且在点击发送短信验证码之前，这个短信验证码的值都会被重置为null。
而且在整个密码找回的过程中，这个(猜想的)send_flag字段应该是跟cookie关联起来了，点击一次即可重复使用。

梳理一下整个流程
第一次输入账号-->发送验证码前,默认短信验证码为null-->发送验证码(send_flag被设置为真，且短信验证码不为null)-->再次回到输入账号界面，输入账号-->发送验证码前(默认短信验证码被重置为null,且send_flag已为真)-->直接输入null通过后端校验-->成功重置密码

由于整个过程都为黑盒测试，猜想也只是笔者自己的天马行空，希望能给各位师傅分享自己挖掘漏洞中的一些奇妙的经历，如果有写得不对不好的地方，欢迎各位师傅指正。