我们来到了Pikachu-Burt Force环节，那么和之前的DVWA又什么不同呐，我们来看看吧！
首先我们看到这个模块有这么几个要点：我们一个一个来！
一、什么是暴力破解：
什么是暴力破解呐：
“暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。
理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。
预防策略：
1.是否要求用户设置复杂的密码；
2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
4.是否采用了双因素认证；
...等等。
漏洞测试流程：
（1）确认登陆接口的脆弱性
确认目标是否存在暴力破解的漏洞。
例如：尝试登陆-抓包-观察验证元素和response信息，判断是否存在被暴力破解的可能。
（2）对字典进行优化
根据实际的情况对字典进行优化，提高爆破的效率。
（3）工具自动化操作
配置自动化工具（例如：线程、超时时间、重试次数等等），进行自动化操作。
二、基于表单的暴力破解实验。
1、首先我们可以随便试一试，看看效果；我们发现密码错误可正确返回信息是不一样的，所以我们很容易想到抓包暴力破解。
那么就来吧！
2、我们设置好代理，随便发送一下用户名和密码，使用Intruder抓包看一下！只是简单的暴力破解就可以解决问题。那么我们就来破解一下用户名和密码。具体主要看截图，已经多次提及。。。。。
只给username和password添加$符号，选择攻击模式为cluster bomb
普及一下小知识：
Sinper：一个变量设置一个payload进行攻击
Battering ram：可以设置两个变量，把payload同时给两个变量
Pitchfork：两个变量分别设置payload，然后按顺序一 一对应进行破解
Cluster bomb：两个变量分别设置payload，然后交叉列所有情况进行破解
3、接下来就是设置字典数据了。两个变量，都要设置上。
4、进入option设置线程：
5、进入grep match模块，大多数情况下我们根据返回页面的length不同观察，但是也可以自己设置falg
将第一步中用户密码登录失败的提示语句复制到下方（username or password is not exists）
6、我们开始破解。发现返回值length长度不同的一个就是用户密码，这也正对应了我们开始的测验。
三、验证码饶过（on client）客户端饶过
1、琢磨这也是变难了！我们看见出现了验证码，看一下源码：
这一关虽然加了验证码，但是通过观察源码可以发现，输入的验证码是通过前端的js进行验证，很轻松就可以绕过，可以说形同虚设
2、老办法抓包看看：
发送到Repeater（Repeater中特别方便不用反复设置代理，抓包），我们前面在sqli-master也用过
我们点击Go，看看情况，发现验证码已经不会再二次检验了！所以验证码就相当于不管用了。
3、然后就和表单破解的方式一致了：发送至Intruder，还是只有用户和密码两个变量，验证码不用管设置payload，设置options
看一下结果！
四、验证码绕过服务端绕过（on server）
我们发现页面和上一个一致，都是有验证码，看看源码吧！
观察源码，这个是在后端的检测的验证码，我们绕过的思路就是观察他产生的验证码有没有过期设置（用过一次刷新），
如果没有，默认的session就是24min刷新，我们看到并没有刷新，也就是短期之内用过的验证码可以重复利用。
不安全的验证码- on server常见问题
@1验证码在后台不过期，导致长期被使用
@2验证码校验不严格，逻辑出现问题
@3验证码设计太过简单和有规律，容易被猜
我们用抓包实验来验证一下吧！
我们发现仍然只是显示账户和密码错误，并没有提及验证码，说明可以二次利用！
接下来还是密码本暴力破解：步骤都一样
五、token可以防爆破？
既然出现了这里，感觉多半是废了！
Token一般用在两个地方:
1)防止表单重复提交、
2)anti csrf攻击（跨站点请求伪造）。
两者在原理上都是通过session token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端
看一下源码，寻找破解奇迹.
我们发现真的设置了一个token值，这样每次提交要验证token值，以“type= ‘hidden’的形式出现在表单，看似可以防止爆破。但是他后端产生的token每次以明文形式传到前端，就有了爆破漏洞。
接下来我们进行抓包实验：
在Intruder处，我们把用户和token设置变量，模式选为pitchfork，在options中的grep-extract中打勾点击add，输入value，点击refetch response ，进行过滤，这个我们之前都在DVWA做过，将取到的token值复制，一会会用，点击ok。
最下方的redirections选择为alway
我的值：724405e8848110130c823591873，这样我们就把返回的这个值弄到，来代替token就可以了。
接下来添加密码字典：
我发现5线程好像不行，出现错误，提示Recursive grep不支持多线程并发，将线程改为1
防暴力破解的措施总结
设计安全的验证码（安全的流程+负载而又可用的图形）；
对认证错误的提交进行计数并给出限制，比如连续5次密码错误，锁定2小时；
必要的情况下，使用双因素认证；
不在多说，和DVWA的暴力破解基本一样，可以去参考一下！