前言： 之前参加一家企业SRC挖洞，正赶上厂商搞活动，秉着有活动我就参加，有漏洞我就捡的良好心态，就去看了一下该企业的一些资产，因为活动是按漏洞危害等级给奖励，所以找一些边缘资产参加活动严重也能给1w也是很香的 正文 随便点了几个站点，发现该企业下已经资产登录、重置密码等功能都是同一套代码，感觉出洞的几率很小，都被大师傅们轮了好几十遍了吧(侥幸心理，但还是建议大家多尝试)，厂家可能是用了单点登录，或者提高代码复用性比较核心的登录等功能走同一接口，为了提高挖洞效率，果断放弃了，点到一处资产，发现登录是单独的一套，引起了我的兴趣，下面进行任意密码重置漏洞的思路剖析。 <1>可以看到，该系统重置密码功能分四步完成，第一步是填写账号，系统去判断该账号是否存在系统，没啥好说的 <2>第二步才是重点，是身份的校验，就是基于第一步判断了用户是注册过的，使用手机号进行身份校验，证明该账号就是你的账号，有的系统使用邮箱、身份证号等类似，点击发送验证码之后，填写正确的验证码就进行服务端验证，验证成功后服务器响应中带一个result随机33位随机数，经过多次尝试发现该值每次获取验证码都会变化，所以可以推算出，下个验证请求会带着这个result值去服务端验证，但是这个地方存在一处缺陷就是，成功通过验证码返回给前端的result值未进行对账号绑定，只是单单对这个验证成功后的result做了服务器缓存处理。 <3>上面就是服务端给你的钥匙(result)是把万能钥匙，没有给你配好锁(手机号),所以我就可以用自己的手机号去获取可以使用的result(钥匙)，然后去开别人家的锁(手机号)，以此达到任意密码重置的目的 细节补充：可以通过修改或直接替换响应来绕过前端对验证码的判断，进到第三步重置密码页面 总结 捡了个严重，又像是没捡，此次是之前总结重置密码思路的其中一种，还请大师傅们多多提出宝贵意见，点点赞。
太强了
哈哈哈哈哈(mmp)，都是兄弟，可能是正常业务升级迭代导致，无法复现
DeepMemory 就差录个视频，扔审核脸上了
DeepMemory 大佬
都哥们😂
东哥的好兄弟
东哥也是嫖了我几个高危，难顶
