分享一下平时实战中密码重置的姿势
因为都是找的实战案例(尽量避免"云渗透")，可能姿势不全(水平有限，如果有缺有错，师傅们多带带)
任意密码重置姿势.jpg

1.重置凭证泄露
很好理解，短信验证码，重置链接等一系列用于重置密码过程认证的值在burp返回包响应泄露。


以上两个案例分别泄露了短信验证码与邮箱重置链接
2.重置接收端可控
若服务端接受的手机号/邮箱是从客户端获取的话，那么就可以修改接收端，让重置信息发给自己手机或是邮箱。
输入admin账号后，服务端返回手机号给前端，获取验证码时，服务端又从前端获取手机号码


3.重置元素弱关联
一次重置过程需要哪些参数参与呢？用户标识/接收端/步骤
用户标识：cookie/username/sid
cookie混淆流程：找回密码时，未登录的cookie本地值不变，可关联多个账号，使用攻击者账号(自己注册的)走完找回密码流程，提交修改密码时截断。用一个新的账号(目标账号)发起流程，然后cookie就会关联目标账号，重放之前的包，就会修改目标账号的密码。
username/sid混淆：修改密码时若是数据包存在类似username=张三&new_pwd=123456的数据包。可替换username=admin&new_pwd=123456，类似修改密码的越权操作吧。
这两个姿势自己没在实战中遇见，就只能云了。
接收端的弱关联：之前遇见一个案例，重置密码需要账号名，身份证号，手机号同时正确才能修改密码。实际上前两个正确就行了。


步骤跳过：这个案例遇见的特别多，当修改密码的操作被才拆分为step1，step2，step3时，我们就可以通过修改响应的状态码来欺骗前端来跳过重置的流程。(响应成功的状态码通常可以在页面的js文件中找)




4.重置凭证未校验
为了防止步骤的跳过，通常最后一步会是这样username=张三&new_pwd=123456&token=11223344，会带一个验证参数，验证参数正确。密码才会修改，这时删除cookie，删除验证参数或许有用。



5.重置凭证可爆破，可预测
可爆破：如果验证码是4位数字，有效期时间足够，而且未设置试错次数的话，可burp直接爆破。
可预测：通过观察token生成的规律，自己伪造，这里面的东西又多了.....
这里再分享两个不同的案例：
案例一：
当我正确输入用户名，身份证号时会把验证码正确和错误的页面一同返回给我。






哈哈这里还有个CSRF。
案例二：
通过在js中找到的未授权的方法，可写入任意用户的资料(改预留手机号)来实现任意用户密码重置。




案例三：
信息泄露导致密码重置，哈哈

End.....