1.验证码绕过(on server)
先进行抓包查看
有验证码的,题目也给了验证码绕过,发送给重发器
在不变且原本为正确的验证码情况下,修改账号密码提示账号或密码错误
而修改了原本正确的验证码后在修改账号密码,发现它说验证码错误
说明在原本验证码正确的情况下,可以一直使用,不用更改它也不会报错
在正确验证码情况下,进行字典爆破
将username和password载入payload的1和2中
得到长度不一样的账号密码
进行尝试登录
能够发现这两个账号密码都是正确的
2.验证码绕过(on client)
抓包,bp查看
模仿前面,看看验证码什么情况
原先正确验证码下修改账号密码,都是账号密码错误
修改验证码后,发现依旧是账号密码错误,那是不是它就是不判断验证码呢?
不用管验证码进行尝试
发现依旧有两个不同寻常的账号密码
尝试登录
发现两个都是可以正确登录的
3.token防爆破
抓包,发现token,而且题目也说了token防爆破
在重发器发现提示
苦苦寻找终于通过别人的博客借鉴发现value=28451658418344f7c5640613521
在bp中可以运用音叉pitchfork攻击模式,进行正则匹配到当前html页面中的value值,放进抓包的value值,然后发送进行爆破
设置三个变量,username和password正常字典即可,token就借鉴学习进行以下设置
有效负载集3中,有效载荷类型改为递归搜索
Token是单次传递,将线程数改为1
在Grep-Extract中add
重定向也改为总是
同时输入第一个请求的初始有效负载
开始攻击,然后发现几个不同寻常的
进行尝试试试看,发现username为admin,password为123456的可行
暴力破解后小结:
- 一般的验证码防范不了,可以采取用手机验证码
- 根据字典攻击可以看,设置错误一次或几次就需要等待XX分钟才能继续登录(可造成拒绝服务攻击)
- Token的更好设置,这里的可以查看导致出现漏洞
- 采取双因素认证
- 用户设置更为复杂的密码