SRC挖掘密码重置漏洞总结
零基础学黑客，搜索公众号：白帽子左一
前言
最近一直在看国外众测的文章，偶尔也逛逛hackerone,发现公布的漏洞中存有不少的逻辑漏洞,毕竟在hackerone上提交漏洞过审之后给的是美元，还是很有诱惑力的。
密码找回功能也是老调常谈的一个功能，前段时间也写过一篇文章是关于密码找回的，发现总结的不是很全面。借这个机会通过展示国外众测例子希望能对这个漏洞有个较为全面的总结
一、 密码重置链接未过期
当用户请求更改密码时，会得到一个密码重置链接来重置密码，该链接应该在一段时间后过期。
如果没有过期可以多次使用密码重置链接来重置密码,那密码重置功能应该存在问题。
在hackerone上找了下，大部分的案例都是先请求获得一个密码重置链接，然后更改获得重置链接的邮箱，发现重置链接没有过期还可以使用，这也算一个思路吧。
但是和我所认知的密码重置链接未过期还是有点偏差的，一般理解的密码重置链接未过期基本上是使用了重置密码链接还能再次使用或者再次获取密码重置链接后前面获取的密码重置链接未失效或者密码重置链接过期时间很长等等，大家都懂啥意思，就不具体举例子了
二、 密码重置无速率限制
我们在通过邮件或者短信获取找回密码的链接的时候由于服务器对获取链接的速率限制不严格或者没有限制,攻击者可以通过重放操作来发送大量的密码重置链接,从而产生短信轰炸或者邮箱轰炸漏洞，在日常的工作中其实可以尝试在email或者电话号码中添加特殊字符比如 空格 +86 ? \等来绕过对email或者电话号码的限制。
常规操作了,原因很多师傅也分析过，这里不在多说。
重放请求包，获取大量的重置密码的邮件:
三 、输入长密码时拒绝服务
密码通常为8-12-24位或最多48位。
如果在设置密码时没有字数限制,当你更改密码或者创建账户检测密码时由于长字符串导致拒绝服务攻击。
总之这算是一个风险点吧,测试的时候可以留意下，万一那天碰到一个系统错误导致溢出敏感数据，那就不单单是个风险点了。
四、 通过密码重置页面进行用户枚举
这个显而易见，有的网站会提醒你输入的用户名或者邮箱是否正确,网站可能在登录做了防护，在忘记密码处可能忘记了。
总之不要错过每一个可以进行信息搜集的地方。
这是一个已经修复好的网站的返回信息，并不告诉你是否发送了邮件，也算是一个规避手段吧。
这漏洞可大可小，总之要在安全和用户体验之间平衡。
五、 host 头中毒
攻击者修改目标的host头将密码重置链接的域名修改为自己的域名。
其实这也是很常见的一种漏洞了,邮件还是发送到受害者的邮箱,如果受害者没注意的话点击链接，攻击者控制的网站的记录中可以查看到请求记录，然后在拼接成正确的域名即可实现任意用户密码重置
更改 host头:
在邮件中可以看到密码重置链接的域名已经被修改为攻击者控制的域名
六、 referer泄漏密码重置令牌
referer请求头包含上一个网页的地址，所以有可能我们在打开重置链接页面时，点击重置链接页面的另一个链接会带上referer，从而泄露密码重置链接。
打开密码重置页面,添加电子邮件并单击发送
点击重置链接,获取重置页面, 点击网页上提供的任何应用程序（twitter、facebook、linkedin），使用burp拦截请求
可以看到在Referer中泄露了密码重置链接
七、 弱凭证问题
如果密码重置链接中包含可以被攻击者轻易猜到的凭证，那这个重置密码链接是不安全的。
最简单粗暴的这种形式，视觉冲击力很强，直接凭证就是用户名,通过枚举出系统中存在的用户名即可实现任意用户密码重置
http://example.com/reset-password?user=victim-user
一个Bugcrowd的例子，重置密码的凭证仅仅是最后的10位数字，和前面那一大串随机字符没关系，你在看是不是就感觉凭证的枚举低多了，去爆破最后几位看看能不能枚举出可用的密码重置链接，很多人一上来看到一大串随机码已经首先放弃了，多想一步可能重置密码就和最后的参数有关系，那岂不是奖金就到手了。
https://redacted.com/update-password/12d52catcbc344ec-9871-85ac6390d863/1621264272
八、 凭证泄露
程序无意中泄露了重置密码的token等重要凭证，导致可以任意重置密码
在请求重置密码时，发送重置请求链接时会发送一个token值:
在走流程到重置密码的时候发现该token同样是重置密码时的token:
所以只要我们输入存在的用户名，然后在请求的时候会获得一个可以用在重置密码时的token从而实现任意密码重置。
九、 使用电子邮件参数重置密码
在受害者请求密码重置链接时，我们可以尝试以下参数操作，攻击者可以获得受害者的密码重置链接
一 双参数(又名HPP/HTTP参数污染)
[email protected][email protected]
二 json表
{“email”:[“[email protected]”,“[email protected]”]}
三 使用分隔符
[email protected],[email protected]
[email protected]%[email protected]
[email protected]|[email protected]
四
[email protected]%0a%0dcc:[email protected]
payload:{“email”:[“[email protected]”,“[email protected]”]}
十、替换返回包中的信息
有时更改密码的跳转是前端控制的，如果更改返回包的内容为正确的内容，比如更改返回包代码等可以绕过限制跳转到更改密码步骤，如果对权限校验不严格的话可以实现任意更改用户密码
用户输入用户名后需要进行安全验证，随便输入答案，将会返回如下内容
HTTP/1.1 401 Unauthorized
(“message”:“unsuccessful”,"statusCode:403,“errorDescription”:“Unsuccessful”)
根据返回包构造下正确的返回包:
(“message”:“success”,"statusCode:200,“errorDescription”:“Success”)
跳转到了更改密码的界面，进行密码的更改
发现密码修改成功,这里修改了密码一定要试下是否修改成功，现在大部分站前端验证是可以跳过，但是最后修改密码是不成功的。
总结
其实吧思路是层出不穷,这只能算是最基本的思路吧。只是希望大家在测试的时候不至于盲目，没有头绪，在基本的操作之上发现骚操作，这应该才是我们的追求。
作者：爱吃猫的闲鱼 原文地址：https://xz.aliyun.com/t/9719
