前言
个人以为，从逻辑漏洞开始挖掘SRC是一个不错的选择。早就在freebuf上将大佬文章收藏，等待之后阅读。
结果这一等遥遥无期，为了治好拖延症，开始阅读大佬文章并进行技术笔记的整理、发布。
一般来说，在挖src的时候，比较容易挖出来的是逻辑漏洞。逻辑漏洞也主要是看个人的思维合攻击面宽度。
这里稍微整理了一些任意用户密码重置以及攻击账号常见手法，笔记来源于Freebuf大神的文章，在这是个人对文章的一些整理和理解，想查看原文可通过如下链接：
https://www.freebuf.com/articles/web/160883.html
任意用户密码重置
这个漏洞常出现的地方有：
新用户注册界面、忘记密码界面、登录后重置密码界面
漏洞成因
一般来说，密码找回逻辑含有用户名、用户ID、cookie；接收端：手机、邮箱；凭证：验证码、token、当前步骤这四步。
四个要素没有完整关联的话，都可能产生任意密码重置漏洞。
验证码回显
在抓包发送的时候，验证码会回显到响应包中，再通过爆破用户名，就可以重置任意用户的密码。
邮件token的构造
邮件找回密码的时候，抓包可能会显示验证用的token信息。
这里的验证方法可以抓包查看是否存在，然后对比发送到邮件的重置链接，查看是否存在关联。
如果可以直接用的话，就可通过构造链接，重置任意账号的密码。
接收端会被篡改
这里分两种情况：
1）请求包包含参数。一个简单的例子，就是通过手机方式找回验证码。接着抓包，将手机号码修改为攻击者手机来获取验证码，之后正常操作。
2）请求包通过后端绑定的号码进行验证。简而言之，在重置密码的时候是以目标账户进行重置。接着会进行身份验证，
此时是通过账号绑定的号码进行验证，请求时将账号参数修改为攻击者参数，这样发送验证码的时候就会发送到攻击者账号所绑定的手机号上。
总结：这两种攻击方式可绕过都是因为验证码与账户未绑定导致的。
Cookie混淆
建议看原文，下面评论有些问题和解答/
https://www.freebuf.com/articles/web/162152.html
一般来说，在重置密码的时候，页面逻辑往往是->输入要重置的账号->验证身份->重置密码
在重置密码这个页面，服务端该如何确认要重置的密码账户呢？
如果是通过cookie中的值来确定的话，就有可能存在cookie混淆的问题。
操作如下：
按照正常流程，到最后输入新密码页面时，先不管。
接着另开一个页面，输入想要重置的账号。到验证界面后，回到第一个页面，提交新密码上传。
接着使用重置的账号和设置的密码可以登录页面，这就是cookie混淆
新密码提交时用户混淆
就是在提交新密码的时候，将用户名修改为其他人的用户名。
这里有个拓展文章，是在freebuf上意外看到的。
https://www.freebuf.com/vuls/239483.html
我的理解是，这个漏洞也是接收端的篡改。重置密码请求时，将用户名（对应这儿的手机号）替换成其他用户名（手机号），进行修改。
不同点在于，这里的请求是经过了加密的。
我认为此处作者能挖出洞关键在于：首先通过经验判断出了是RSA加密，且在源代码中多个js脚本含有“RSA”名称，于是联想到这是客户端加密。
通过前台调用rsa函数方法，可以直接指定账号进行加密，然后提交修改过的用户名，成功重置密码。
阅读的时候有这么一个问题：为什么不直接拿其他账号用户名加密后的参数替换呢？
且在原文中作者也尝试过，但是失败了。
查阅资料后发现，RSA加密，虽然加密函数是一样的，但是某些填充值不一定相同。
比如以会话参数作填充值的话，每次刷新页面，加密串都不一样，也就导致了不能直接拿来利用。
篡改带token的重置链接中的用户名
在带token的重置链接中可能出现用户名id（可能经过加密等一系列措施），然后对用户名id进行修改，就可以重置任意其他用户。
在本篇文章中，出现了一个REST风格。
经过查阅资料后，REST风格大致是/user/100这种类型，其中100是user的id。
这里存在一个拓展，REST风格下的几个安全问题。
参考原文：https://blog.csdn.net/jackyrongvip/article/details/84834058
REST风格常见的安全漏洞：
1）REST第一个典型的安全漏洞，就是对用户ID没有校验，使得可以通过遍历ID查看到其他用户的信息。
一般来说，只出现一个资源的时候都已经做了安全防御。但是出现多个资源的时候就不一定了。
比如订单链接，/user/100/orders/1，对1进行遍历，说不定可以查看所有订单，甚至进行操作。
2）这个文章说的是HTTP安全响应，以及他们对应的一些功能。
X-Frame-Options：防点击劫持，其中deny告诉浏览器，不要将当前响应内容在html frame中显示出来。
3）REST会推断响应的内容是不是脚本，且不会管content-type类型，如果推断出是脚本的话，那就会直接按照脚本来执行。
修复建议：添加X-Content-Type-Options可以使其严格按照content-type中的类型来执行格式。
4）信息泄露
前后端分离的时候，会以json作为传输数据的载体，有时候json会返回多余信息，造成信息泄露。
5）可能会存在短信轰炸
验证码未校验
验证码说得比较笼统，根据找回密码的验证大致可以分为两类。一类是验证码，另一类就是密保问题。
第一种场景应用方式：带token的链接服务端未进行验证。简单地说，就是验证的key完全没有效果，任意输都行。
第二种场景：对所有的用户名进行遍历，里边一般会有三种情况：存在且设置了密保的，存在但没设置密保，没这个用户。
可以爆破出用户名出来，然后对未设置密保的用户进行密码重置。
验证码爆破
顾名思义，当验证码长度不算长的时候，而且没限制高频登录的话，就可以进行爆破。
这里可以使用burp的进阶工具turbo intruder，相关文章介绍链接在这：
https://www.secpulse.com/archives/126527.html
具体的会新开一篇进行记录。
顺带，在爆破中如果ip受限的话，有几个方法可以解决：伪造ip、使用代理池。
伪造IP的话，根据网站服务端验证客户端IP首部的方式，可以用burp自动生成。
比如，在请求首部添加：X-Forwarded-For：128.64.$32$.$22$,最后两个字段设置成了枚举变量，就有了整个B段的随机IP。
至于代理池的话，可以使用免费的代理池服务，用脚本调用curl发起http请求，设置–proxy参数指定代理ip
更改应答值
有的时候，服务器校验了验证码正确之后，会将结果状态值下发客户端，后续的步骤则依靠前端js判断是否可进入第三步。
这个时候，修改应答包的状态值，就可以进入重置密码界面。
token可预测
通过邮箱找回密码的时候，邮件中一般会附带一个含有token的重置url。
这个token就是重置凭证。只不过开发人员习惯以时间戳、递增序号、关键字段作为部分，采用某种加密算法或编码生成。
要预测这个token，就可以基于收集到的账号等关键信息，用常见的加密算法计算一遍，就能判断是否可以预测token了。
作者用了两个案例，其中第一个案例是一道CTF赛题，解题思路如下：
重置链接中存在一个key，这个key显然就是重置token。对其进行md5解密得到一串时间戳明文。
那么攻击方式如下：
攻击者账户重置，得到url时间戳->攻击者重置admin，无法得到时间戳->攻击者再此重置自身账户，得到重置时间戳。
那么admin对应的时间戳就在这两个时间戳区间，对其进行爆破即可。
第二个案例：基于递增序号的token
这个就是token会按照一定规律递增，对重置邮件的token多关注比较即可。
第三个案例：所举的案例都是token经过MD5加密而成。比如MD5（手机号+验证码），token根据关键字段组合加密而成。
结语
以上就是大佬文章中对于任意用户密码重置这个逻辑漏洞的总结以及自身的一些记录。总的来说，逻辑漏洞多种多样，还是需要不断的积累与视角的开阔还有长期的练习。对常见的加密形式也应有了解，DES\AES\RSA\MD5等等……
