目录
字典获取
BP四种攻击模式
一、Sniper(狙击手模式)
二、Battering ram(攻城锤模式)
三、Pitchfork(叉子模式)
四、Cluster bomb(炸弹模式)
靶场练习
基于表单的暴力破解
验证码绕过(on server)
验证码绕过(on client)
token防爆破?
字典获取
在github里找到心仪的字典之后，拿字典的名字到gitee上搜索和下载
BP四种攻击模式
一、Sniper(狙击手模式)
将bp截的包各个用$$符号标记的数据进行逐个遍历替换
假设确定了两个位置A和B，然后密码包payload里有两个密码1、2，那么攻击模式如下：
一次只会对一个位置进行攻击
| Attack No. | Position A | Position B |
| 0 | 1 | null |
| 1 | 2 | null |
| 2 | null | 1 |
| 3 | null | 2 |
二、Battering ram(攻城锤模式)
于sniper模式不同的地方在于，同样情况下，攻击次数减半，每次两个位置用同样的密码，如表：
| Attack No. | Position A | Position B |
| 0 | 1 | 1 |
| 1 | 2 | 2 |
三、Pitchfork(叉子模式)
多组密码本payload，一一对应，现在添加包含3、4的密码本payload，暴力破解过程如表：
| Attack No. | Position A | Position B |
| 0 | 1 | 3 |
| 1 | 2 | 4 |
pl1：1，2
pl2：3，4
那么第一爆破为 1，3
而二次爆破为2，4
四、Cluster bomb(炸弹模式)
跟叉子模式相似的是多个密码本对应多个位置，不同的是不再是一一对应，而是交叉组合，每一个密码本里的密码都对应于另一密码本所有密码，如表：
| Attack No. | Position A | Position B |
| 0 | 1 | 3 |
| 1 | 2 | 3 |
| 2 | 1 | 4 |
| 3 | 2 | 4 |
靶场练习
基于表单的暴力破解
勾选爆破点
选择simple list并load字典文件 
length排序后发现爆破成功
这里一共发了18(3*6)个请求，因为我们使用的是3*6的密码本且选择了Cluster bomb(炸弹模式)
验证码绕过(on server)
源码
if (strtolower($_POST['vcode']) != strtolower($_SESSION['vcode'])) {
$html .= "<p class='notice'>验证码输入错误哦！</p>";
//应该在验证完成后,销毁该$_SESSION['vcode']
}else{
$username = $_POST['username'];
$password = $_POST['password'];
$vcode = $_POST['vcode'];
$sql = "select * from users where username=? and password=md5(?)";
$line_pre = $link->prepare($sql);
$line_pre->bind_param('ss',$username,$password);
if($line_pre->execute()){
$line_pre->store_result();
//虽然前面做了为空判断,但最后,却没有验证验证码!!!
if($line_pre->num_rows()==1){
$html.='<p> login success</p>';
}else{
$html.= '<p> username or password is not exists～</p>';
}用户名和密码输入错误值，当验证码是错误值时，返回提示验证码错误。用户名和密码输入错误值，当验证码是正确值时，返回提示用户名或密码不存在。并且每次提交都会自动刷新验证码，那有没有可能，我只要不在网页上点Login，不刷新网页，网页当前显示的验证码就一直有效呢？
可以看到验证码在判断完之后不会销毁，而是在页面刷新之后验证码才会刷新
只要我使用bp的重放攻击，页面是不会刷新的，那样就可以重复利用该验证码
验证码不用设置payload点，与当前页面显示的相同即可
依旧选择 Cluster bomb(炸弹模式)，共发送5*6=30个包
跑出来两个账号
验证码绕过(on client)
用户名和密码输入错误值，当验证码是正确值时，返回提示用户名或密码不存在。用户名和密码输入错误值，当验证码是错误值时，有弹框提示验证码错误。验证码错误时有弹框这点，怀疑用户名和密码是在后端验证的，但验证码是在前端验证的。查看网页源代码，发现果然前端有检验验证码的js脚本，到目前为止一切就清楚啦，既然是前端检测，那直接用burpsuite发请求报文绕过前端就可以了。
这里输入的验证码要跟图片的一样，先过了前端检测才能抓到数据包，不然前端验证码检测没过他会弹窗，导致数据包无法抓取，也就不能暴力破解
抓取到数据包之后，故意将验证码随意修改，反正发到后端也不会检测
token防爆破?
服务器新增检测条件token，客户端每次访问都必须带着服务器下发的token，否则登录失败。
发现response中网页源代码有一个type为hidden，name为token的input标签，value和request报文的token不一样，应该是下一个报文的token。根据以上结果，下一次request需要携带的token就是上一次response中html代码中的隐藏字段值，也就是说request中的token是可以从上一个response中提取的。
第三个payload type设置为Recursive grep
