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

点击收藏 | 3 关注 | 3
登录 后跟帖