传统型爆破思路，用户名可以通过猜测或者信息收集获得。
猜测：admin、网站域名等
信息收集：新闻发布人、whoami等
如果是后台登陆处，那么性价比会降低，因为后台登陆处，用户名可能会很少，甚至只有一个。
更加适用于普通用户登陆处。
指定弱口令爆破用户名，拿TOP1弱口令123456尝试，百试不爽。
分享一个遇到过的看似比较费劲的防御措施
编写脚本绕过防御策略
再分享一次遇到特别恶心的一次，用BurpSuite爆破时，响应包长度、状态码完全相同；
那时候还没有设置关键字匹配数据包的意识，甚是悲催，
我说：没有弱口令；同事：有啊，分明有很多。
在爆破的时候，添加匹配关键字：
可以添加登陆成功时，独有的关键字；
也可以添加登陆失败时，独有的关键字。
然后返回结果这里，便会发现多出了一列，匹配到关键字的带有对勾，没有匹配到的则空白
经测试发现用户登陆处存在XSS，但只是Self-XSS，自己插自己，不用灰心，再看看这个登录框是否存在CSRF即可。
构造CSRF POC，将XSS的payload放到用户名这里。
测试后，发现成功弹窗
如果登陆框附近存在用户注册功能时，可以尝试
如校验值默认为空
简单粗暴
任意密码重置姿势太多，附上我做的脑图
赘述一种我比较喜欢的方式，在找回密码处不存在任意密码重置漏洞时，不用灰心，登陆进去，在个人中心处依旧会有很大几率存在任意密码重置漏洞。
如：
CSRF重新绑定手机号、邮箱号，
重新绑定时，用户身份可控，如最后的请求包可以通过修改用户id来控制绑定的用户
存在用户注册、用户找回密码等功能时，尝试是否存在短信炸弹
指定单个用户，然后重放发送短信的HTTP请求。
BurpSuite中的一个Tricks：不修改参数，直接重放数据包，对于短信炸弹的测试非常实用
每次测试这个，都是使用学校里的手机卡，遍历后面的几位，这样就可以直接询问同学是否收到短信；
每次都很刺激。
我是渗透测试工作者，平时喜欢研究安全方面的内容，如果你也对这方面感兴趣，可以一起交流，也可以【点我查看】网络安全学习文档
传统型爆破思路，用户名可以通过猜测或者信息收集获得。
猜测：admin、网站域名等
信息收集：新闻发布人、whoami等
如果是后台登陆处，那么性价比会降低，因为后台登陆处，用户名可能会很少，甚至只有一个。
更加适用于普通用户登陆处。
指定弱口令爆破用户名，拿TOP1弱口令123456尝试，百试不爽。
分享一个遇到过的看似比较费劲的防御措施
编写脚本绕过防御策略
再分享一次遇到特别恶心的一次，用BurpSuite爆破时，响应包长度、状态码完全相同；
那时候还没有设置关键字匹配数据包的意识，甚是悲催，
我说：没有弱口令；同事：有啊，分明有很多。
在爆破的时候，添加匹配关键字：
可以添加登陆成功时，独有的关键字；
也可以添加登陆失败时，独有的关键字。
然后返回结果这里，便会发现多出了一列，匹配到关键字的带有对勾，没有匹配到的则空白
经测试发现用户登陆处存在XSS，但只是Self-XSS，自己插自己，不用灰心，再看看这个登录框是否存在CSRF即可。
构造CSRF POC，将XSS的payload放到用户名这里。
测试后，发现成功弹窗
如果登陆框附近存在用户注册功能时，可以尝试
如校验值默认为空
简单粗暴
任意密码重置姿势太多，附上我做的脑图
赘述一种我比较喜欢的方式，在找回密码处不存在任意密码重置漏洞时，不用灰心，登陆进去，在个人中心处依旧会有很大几率存在任意密码重置漏洞。
如：
CSRF重新绑定手机号、邮箱号，
重新绑定时，用户身份可控，如最后的请求包可以通过修改用户id来控制绑定的用户
存在用户注册、用户找回密码等功能时，尝试是否存在短信炸弹
指定单个用户，然后重放发送短信的HTTP请求。
BurpSuite中的一个Tricks：不修改参数，直接重放数据包，对于短信炸弹的测试非常实用
每次测试这个，都是使用学校里的手机卡，遍历后面的几位，这样就可以直接询问同学是否收到短信；
每次都很刺激。
京公网安备 11010802035086号