SRC漏洞挖掘过程中遇到登录框时，总是感觉自己测试不完全，东一榔头西一棒子，想起什么来测什么。
感觉这样不太行，显得不专业，于是乎总结一下，在以后的测试过程中可以作为笔记提示。
以下按照顺序测试：
注册页面
- 注册页面批量注册
- 注册覆盖（重复注册他人账号）
- 短信邮件炸弹
- 手机验证码是否可爆破（老生常谈，Burpsuite抓包爆破四位验证码）
- 图片验证码是否可绕过（验证码缺失、验证码失效数据包重放、万能验证码0000、验证码空绕过、验证码前端获取(极少数情况)）
登录页面
- 弱密码、无验证码爆破、万能密码（后台登录，用户登录次数限制）
- 手机验证码登录是否可以进行短信炸弹
- url跳转漏洞（主要用来钓鱼，对于绕过和利用百度搜索已有大量文章，不赘述）
- 登录处是否可绕过（对于大多数没有cookie的网站）
- 用户名枚举（观察返回包提示或者返回包参数变化）
忘记密码
- 手机验证码是否可爆破
- 修改密码流程是否可跳过
- 任意用户密码重置
- 短信邮件炸弹
这种网站注册页面，没有手机短信验证码，那么，我们可以考虑，是否可以批量注册呢？
对于批量注册的前提是：该页面处没有图形验证码或者图形验证码失效！该页面注册处没有图形验证码。
注册页面虽然需要输入姓名和身份证号，但是并未对姓名和身份证号去做核对，输入任意的姓名和身份证号即可。
测试过程：注册提交时Burpsuite抓包
先用正确的信息注册，记住注册成功时服务器返回的数据，知道注册成功是返回什么
然后使用刚才的数据包遍历修改手机号，账号等参数发送，观察回复的数据包状态
对于注册页面覆盖注册是指原来用一个手机号已经注册了账号，但是由于漏洞，导致可以再利用该手机号进行注册，并且会将之前注册的记录覆盖！
当我们用已经注册了的账号准备再注册时，发现会提示该手机号码已经存在！
我们抓包，发现后端检测该手机号已经注册了的话，会返回 true。如果检测该手机号没注册的话，会返回false。
修改回传参数，达到重复注册目的。
其实这就是个限流的问题——也就是限制某个接口的时间窗口内的请求数。
很多项目都少不了给用户手机号或者邮箱账号发短信邮件之类的，但是很多发送短信都是借助于第三方接口来发送短信的，这样一来，发送的短信就是有限制的，收费的哦。如果系统做的不太好，有些小漏洞，被白帽子发现还好，要是被那些黑帽子发现了，少则几千，严重者可能导致公司倒闭啊。即使不被黑帽子攻击，有些恶意的用户也可能系统进行破坏。
也可使用Burpsuite抓包爆破，西门吹雪大佬有过一个抓包给手机号后依次添加空格的实例
防范措施：
1. 限制每个手机号的每日发送次数，超过次数则拒发送，提示超过当日次数。
2. 每个ip限制最大限制次数。超过次数则拒发送，提示超过ip当日发送最大次数。
3. 限制每个手机号发送的时间间隔，比如两分钟，没超过2分钟，不允许发送，提示操作频繁。
4. 发送短信增加图片验证码，服务端和输入验证码对比，不一致则拒绝发送。
不可靠的前端校验
还是会有许多的网站他们没有严格进行身份校验，他们往往是通过依靠帐号密码登陆后发送后回传的JSON数据来判断用户身份是否正确，这就暴露出了很大的漏洞，这种漏洞利用起来就相当的容易，往往只需要一个安全界的神器 BURP 就可以完成身份验证的绕过，在登录的时候输入正确的账户以及随意的密码，将报文拦截下来，然后选择 burp 里面的拦截返回包的功能，捕捉返回的状态码。
几乎所有需要登录的网站都有一个忘记密码然后重置密码的功能，如果网站在密码重置功能处的代码不够严谨，将可能造成任意密码重置的逻辑漏洞。
1、 验证码失效，导致攻击者可以通过爆破其他用户手机验证码来实现任意用户密码重置
·2、验证码未绑定用户：也就是我们可以利用自己的手机号来进行成功验证手机验证码，然而在提交修改密码处提交其他人的手机号，来实现修改其他人的密码
·3、修改接收验证码的手机或邮箱：当我们修改密码时，输入正确的用户名，点击发送验证码，抓包，发现数据包中有该用户名对应的手机或者邮箱，我们将其修改为自己的手机或邮箱来接收验证码。输入我们收到的验证码，即可实现对该用户的密码进行重置。(这里还存在一个信息泄露，即知道用户名就能知道该用户对于的手机或邮箱)
·4、跳过验证步骤：网站对修改密码的步骤，没有做校验，导致可以直接输入最终修改密码的链接，直接跳转到该页面，然后输入新密码达到重置密码的目的。首先使用我们自己的账号走一次流程，获取每个步骤的页面链接，然后记录页面3对应的输入新密码的链接，重置他人用户时，获取验证码后，直接输入密码修改页面链接到新密码的界面，输入密码重置成功。
5、 cookie值的替换：重置密码走到最后一步的时候仅判断唯一的用户标识cookie，并没有判断该cookie有没有通过之前重置密码过程的验证，导致可替换cookie重置他人用户密码。重置自己用户密码到达最后阶段，抓到数据包，并在第一阶段重新获取其他用户cookie，替换cookie到我们抓取的数据包中，发包测试。