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

暗码找回逻辑含有用户标识（用户名、用户 ID、cookie）、接纳端（手机、邮箱）、凭据（验证码、token）、当时过程等四个要素，若这几个要素没有完好相关，则或许导致恣意暗码重置缝隙。

事例一：接纳端可篡改。恳求包中包括接纳端参数，可将凭据发至指定接纳端。
暗码重置页面，输入恣意一般账号，挑选手机 *** 找回暗码。在身份验证页面点击获取短信验证码：

阻拦恳求，发现接纳验证码的手机号为恳求包中的参数：

直接篡改为进犯者的手机号，成功接纳短信验证码，提交验证码后，正常履行 3、4 步即可成功重置该账号的暗码。
事例二：接纳端可篡改。恳求包中呈现接纳端直接相关参数，可将凭据发至指定接纳端。
在暗码找回页面，用进犯账号 test0141，测验重置方针账号 2803870097 的暗码（对滴，你没看错，这两个长得彻底不像的账号的确是同个网站的）。
在之一个主页中输入 test0141 和图片验证码完结“01 安全认证”：

恳求为：

输入图片验证码获取短信验证码完结“02 身份验证”：

恳求为：

后续的 03、04 步不触及用户名信息，疏忽。
全流程下来，客户端并未直接提交接纳短信验证码的手机号，屡次测验可知，02 中呈现的 user_name 用于查询下发短信的手机号，用它能够直接指定接纳端，那么，它是否仅此效果而不用于指定重置暗码的账号？如下思路验证，先将 userName 置为 2803870097 完结 01 以告知服务端重置的账号，再将 user_name 置为 test0141 完结 02 以诈骗服务端将短信验证码发至进犯者手机，次序完结 03、04 或许能完成重置 2803870097 的暗码。详细如下。
之一步，用一般账号 2803870097 进行安全认证：

第二步，对一般账号 2803870097 进行身份验证：

阻拦发送短信验证码的恳求：

将 user_name 从 2803870097 篡改为 test0141，操控服务端将验证码发至 test0141 绑定的手机号：

test0141 的手机号成功接纳到验证码 872502，将该验证码填入重置 2803870097 的身份校验页面后提交：

第三步，输入新暗码 PenTest1024 后提交，体系提示重置成功：

第四步，用 2803870097/PenTest1024 登录，验证成功：

防护办法方面，必定要将重置用户与接纳重置凭据的手机号/邮箱作一致性比较，一般直接从服务端直接生成手机号/邮箱，不从客户端获取。