业务逻辑安全
最近在看《Web攻防业务安全实战指南》，接合一些漏洞，先总结一下密码重置和爆破方面的知识，做一个记录。希望对你有帮助。
关于密码重置，之前钉钉培训中，有一位大佬讲的很透彻，也可以学习一下。
暴力破解
暴力破解：逐个的对应用程序登录处进行账号和密码的穷举，直到找到正确的用户名和密码。
- 知道用户名，破解密码
- 使用弱密码，爆破用户名
用户名和密码的混合爆破
案例
无验证码
登录框没有验证码和登录次数限制。使用弱密码
123456爆破用户名。
https://bugs.shuimugan.com/bug/view?bug_no=223897有验证码
验证码一直不会变
https://bugs.shuimugan.com/bug/view?bug_no=58751
https://bugs.shuimugan.com/bug/view?bug_no=203629
文章聚合
https://bbs.ichunqiu.com/thread-45640-1-1.html
https://bbs.ichunqiu.com/thread-16539-1-1.html
https://t0data.gitbooks.io/burpsuite/content/chapter8.html
https://www.secbug.net/websec/164.html
密码重置
1: 修改返回包
在本地验证服务端的返回信息——修改返回包绕过验证
在修改密码处，有的时候要求输入验证码或者设置的安全问题。随便输入，然后抓返回包，修改其中的值。
如果知道正常的修改密码的返回包，对比一下，来修改。测试的时候，根据返回包的内容，比如false修改true之类的。
原理和方法
Response状态值修改测试，即修改请求的响应结果来达到密码重置的目的，存在这样漏洞的网站或者手机App往往因为校验不严格而导致非常严重的密码重置操作。
这种漏洞的利用方式通常在服务端发送某个密码重置的凭证请求后，出现特定的响应值，比如true，1，ok，success等，网站看到回显内容为特定值后修改密码。通常这种漏洞的回显值校验是在客户端进行的，所以只需修改回显即可。
案例
https://bugs.shuimugan.com/bug/view?bug_no=207115
https://bugs.shuimugan.com/bug/view?bug_no=204835
修复建议
注意不要在前端利用服务端返回值判断是否可以修改密码，要把整个校验环节交给服务端验证。
2: 爆破验证码
密码找回的时候，会发送到手机或者邮箱一个验证码。当这个凭证的验证次数没有进行限制或限制不严格的话，可被绕过。
原理和方法
找回密码功能模块中通常会将用户凭证(一般为验证码或者链接)发送到用户的手机或者邮箱中，只要用户不泄漏自己的验证码就不会被攻击者利用。如果应用程序的验证码发送模块中验证码位数及复杂性较弱，也没有对验证码的次数进行限制可被暴力破解。
观察验证码的发送规律，比如四位或者六位纯数字。
案例
https://bugs.shuimugan.com/bug/view?bug_no=205795
https://bugs.shuimugan.com/bug/view?bug_no=203274
https://bugs.shuimugan.com/bug/view?bug_no=021722
https://bbs.ichunqiu.com/forum.php?mod=viewthread&tid=3212&fromuid=222307
修复建议
为了避免验证码被暴力破解，建议对用户输入的验证码校验采取错误次数限制和验证码有效时间。
3 验证码回显在客户端
有时候在响应包中，直接可以看到验证码的，这个时候就不需要爆破了，直接利用。
原理和方法
找回密码测试要注意验证码是否会在响应包中。
案例
https://bugs.shuimugan.com/bug/view?bug_no=205365
修复建议
避免返回验证码到响应包中，验证码一定要放在服务端校验。
4: 修改接收验证码的手机/邮箱
攻击者用自己手机号码收到的重置用短信验证码可以重置其它用户的密码。没有验证手机号或者邮箱的对应身份导致该漏洞。
原理和方法
找回密码功能逻辑中通常会在用户修改密码接口提交参数中存在传递用户账号的参数，比如是邮箱或者手机号。抓包修改其中的参数为自己的手机号，就能收到验证码，达到重置密码的效果。
案例
https://bugs.shuimugan.com/bug/view?bug_no=205445
https://www.secpulse.com/archives/20787.html
https://bugs.shuimugan.com/bug/view?bug_no=021771
修复建议
在找回密码的Token做一对一的校验，一个Token只能修改一个用户，同时一定保证Token不泄漏。
5: 重置步骤未进行校验
重置密码的步骤一般为：
1.输入账户名2.验证身份3.重置密码4.完成。
有时候当你进行了1之后，直接去修改URL或者前端代码去进行3步骤从而也能成功的绕过了2的验证去重置密码。这种一般是由于没有对关键的身份验证的参数进行追踪导致的。
从前端找到步骤3的URL，直接访问，跳过2的验证身份。
案例
https://bugs.shuimugan.com/bug/view?bug_no=211505
https://bugs.shuimugan.com/bug/view?bug_no=054890
修复建议
防止跳过验证步骤一定在后端逻辑校验中确认上一步流程是否已经完成。
6: Session 覆盖
在某些网站中的找回密码功能中，业务逻辑是：由用户使用手机进行注册，然后服务端向手机发送验证码短信，用户输入验证码提交后，进入密码重置页面。
对网站的session覆盖的测试为：
使用A账户正常进入重置页面，这个时候在浏览器页面中重新打开密码找回页面，输入B用户的账户，这个时候再来到A账户重置密码页面，此时Session会被覆盖，可重置B用户的密码。
案例
https://bugs.shuimugan.com/bug/view?bug_no=225958
修复建议
在重置密码请求中，对账户和凭证是否一致要做进一步的校验。
7: 其他
找回密码链接中敏感参数的替换。
https://bugs.shuimugan.com/bug/view?bug_no=206447
文章聚合
http://www.freebuf.com/author/yangyangwithgnu
http://www.freebuf.com/articles/web/21214.html
https://www.ichunqiu.com/course/59045
https://blkstone.github.io/2017/10/11/common-password-reset-vuln/
https://wps2015.org/drops/drops/%E4%B8%80%E4%BA%9B%E5%B8%B8%E8%A7%81%E7%9A%84%E9%87%8D%E7%BD%AE%E5%AF%86%E7%A0%81%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%E6%95%B4%E7%90%86.html
http://www.nxadmin.com/web/1642.html