场景一【验证码位数过短】：
在业务逻辑测试很多时候涉及到重置密码、重置身份信息等。这时候的验证信息（短信、邮件链接等）也是我们要考虑的点之一。
可以用自己的账号注册，模拟重置用户信息。查看手机接收到的验证有没有特点。（比如Google 8位 支付宝6位等）。验证码过短（甚至是验证码有规律）的时候就可以尝试是否能通过爆破的方式猜测出验证码。
条件a：验证码够短 条件b：在提交的时候没有图像验证（当然，如果你能绕过的话另说） 条件c：服务端没有限制重复提交次数等机制
场景二【验证码返回到response信息中】：
这个相当相当相当的常见....
位置a：返回的url或者token中 位置b：返回的response信息中（最常见）
场景三【重置信息被伪造】：
这个在一些大案例也有...
1.如：触发重置密码的只是，系统往你的邮箱发送一条重置链接。http://xxoo.com/resetpwd.php?user=5d41402abc4b2a76b9719d911017c592。只要点击这个链接就能重置。 2.简单分析可以发现 user的参数值其实就是简单的md5过的（当然了还有其他方式。） 3.这时候如果将我们想要重置的账号 如admin 21232f297a57a5a743894a0e4a801fc3。构造一条链接“ http://xxoo.com/resetpwd.php?user=21232f297a57a5a743894a0e4a801fc3 4.如果其实没有其他判断机制，造成越权重置。
场景四【移花接木】：
额...也不知道开发同学是怎么想的。
假设场景： 冒用A用户触发忘记密码并提交重置密码申请 => 系统发验证信息【比如 888888】到A绑定的（手机、邮箱等） 工程师即刻用自己的账号同样触发忘记密码并提交重置密码申请 => 系统发验证信息【比如 123456】到工程师绑定的（手机、邮箱等） 这时候用工程师自己手机号（邮箱）获取的验证码【123456】填到A用户的重置流程中 => 成功重置A的密码 混乱吧....
场景五【暗度陈仓】：
额...
假设场景： step1：冒用A用户触发忘记密码并提交重置密码申请 step2：要求输入A用户绑定的手机号（邮箱） getit（这时候把手机号填成工程师自己的手机号或邮箱） step3如果这时候系统没有认证，就会讲A用户的重置密码发到工程师自己的手机号 ...
场景六【一步到位】：
额...
有自己搭网站的同学应该清楚很多博客系统在部署的时候会先判断环境变量是否满足、其次要你输入mysql账号密码、最后让你设置一个管理后台密码。 没错！有个流程... 在看看业务逻辑上会碰到啥情况呢？ step1：A用户触发【http://xxoo.com/forgotpwd.php?user=hello&step=1】忘记密码 step2：【http://xxoo.com/forgotpwd.php?user=hello&step=2】 系统要求用户输入注册时留下的手机号（邮箱） step3：如果系统发现信息匹配，则跳转到step3【http://xxoo.com/forgotpwd.php?user=hello&step=3】 一切看起来很和谐~ 但是 如果系统没有相关的处理机制呢？工程师在不知道A的手机号，直接构造个step3页面呢？ ....
场景七【形同虚设】：
额...
这个跟之前讲过的图像验证码有点像。 系统虽然要求用户输入绑定的手机号、并获取到验证码。但是在最终提示的时候。用户把验证码参数删掉 => 提交成功。 这个是由于系统仅仅根据客户端其实是信息进行判断。对缺少的部分并没去关注！