一个稍显诡异的逻辑缝隙，且学且思考！ 在某次挖掘缝隙练手的历程中，遇到过一个比力出格的逻辑缝隙。之所以说比力出格是因为缝隙是偶尔之间触发的，而且我本人在缝隙触发之后也是花了快半小时才理清这个逻辑缝隙要怎么复现。直接来到缝隙页面，如下图。

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

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

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

展开全文 缝隙挖掘的时候，本身第一次乐成触发是在验证码处输入了null，然后乐成第一次重置了某个同学的暗码，如图 其实其时我本身长短常懵的，感受有点莫名奇妙。追念一下暗码重置的校验历程 输入账号--》校验是否发送验证码--》校验验证码是否正确--》暗码重置乐成 其时测试了半个多小时吧，最终乐成复现。先讲一下如何完整复现这个暗码找回的逻辑缝隙，再料想为何有这种行为。第一步 输入用户账号和验证码 第二步 点击发送短信验证码 乐成获取验证码后可以看到提示信息 第三步 此时再度点击，通过手机号找回暗码 第四步 从头输入适才的账号(注意这里必需是同一个账号才行)，验证码 第五步 直接来到了适才的短信验证码界面，可是这次不需要发短信了，直接输入null，提交 第六步 来到暗码重置界面，直接配置暗码就可以重置了 登录验证下。

没问题 按照缝隙挖掘的历程 料想这个逻辑缝隙后端应该有如下逻辑 有一个校验短信验证码的字段，这里暂且叫send_flag 默认应该为false，发送短信后被配置为true。这里能乐成重置用户暗码的关键也在于存在一个默认的短信验证码null。按照逻辑缝隙的行为可以斗胆料想每次用户点击通过手机找回暗码后，且在点击发送短信验证码之前，这个短信验证码的值城市被重置为null。

并且在整个暗码找回的历程中，这个(料想的)send_flag字段应该是跟cookie关联起来了，点击一次即可反复使用。梳理一下整个流程 第一次输入账号-->发送验证码前,默认短信验证码为null-->发送验证码(send_flag被配置为真，且短信验证码不为null)-->再次回到输入账号界面，输入账号-->发送验证码前(默认短信验证码被重置为null,且send_flag已为真)-->直接输入null通事后端校验-->乐成重置暗码 文：irrik 原文链接：https://xz.aliyun.com/t/8344 基础教程返回，检察更多。

本文来源：开云娱乐官网-www.icn-tech.com