在逻辑缝隙中，恣意用户暗码重置最为常见，或许出现在新用户注册页面，也或许是用户登录后重置暗码的页面，或许用户忘掉暗码时的暗码找回页面，其间，暗码找回功用是重灾区。我把日常浸透过程中遇到的事例作了缝隙成因剖析，这次，重视因重置凭据可暴破导致的恣意用户暗码重置问题。

暗码找回流程一般包含获取短信验证码、校验短信验证码是否有用、设置新暗码等三个过程。在第二步，校验短信验证码是否有用的成果应保存在服务端，某些网站未在服务端保存而是过错地将成果状况值下发客户端，后续又依托前端 js 判别是否能够进入第三步，那么，更改应对包中的状况值，可重置其他用户的暗码。
事例一
在暗码找回页面 http://www.xx.cn/yy/action/forgot 用攻击者手机号 13908081024 进入暗码找回全流程，获取短信验证码 033128、输入图片验证码、输入短信验证码并提交：

服务端校验通往后，体系应对如下：

简略剖析发现，校验经过期服务端并未向客户端 set-cookie，猜想服务端并未记载校验状况，是否进入设置新暗码页面完全是由前端 js 根据应对状况决议的，那么，即使我没有短信验证码，经过将服务端下发给客户端的校验状况从“失利”改为“成功”，也能成功重置找回账号暗码。
详细而言，以信息收集时找到的 *** 手机号 13980808888 为例。输入手机号、获取短信验证码、输入图片验证码、输入过错的短信验证码 123123 后提交：

因为短信验证码过错，体系校验必定失利，体系应对如下：

阻拦该应对，用前面抓取校验成功的应对包替换之：

放行至客户端，顺畅进入新暗码设置页面：

输入新暗码 PenTest1024 后提交，页面提示暗码修正成功：

尝试用 13980808888/PenTest1024 登录，验证成功：

事例二
在暗码找回页面 http://www.xx.cn/yy/forgot 用攻击者手机号 13908081024 进入暗码找回全流程，获取短信验证码 2118、输入短信验证码并提交：

服务端校验通往后，体系应对如下：

简略剖析发现，校验经过期服务端并未向客户端 set-cookie，将服务端下发给客户端的校验状况 code 改为“0000”，能够重置其他用户暗码。
详细而言，以土豪手机号 13888888888 为例。输入手机号、获取短信验证码、输入过错的短信验证码 1234 后提交。因为短信验证码过错，服务端校验失利，应对如下：

阻拦该应对，用前面抓取校验成功的应对包替换之后，放行至客户端，顺畅进入新暗码设置页面：

输入新暗码 PenTest1024 后提交，页面提示暗码修正成功。尝试用 13888888888/PenTest1024 登录，验证成功：

加固办法
服务端校验短信验证码后应经过 cookie 记载状况，不该在前端经过状况参数判别。别的，服务端应约束枚举等歹意恳求。