一、Burte Force（暴力破解）概述

​ “暴力破解”是一攻击具手段，在web攻击中，一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录，直到得到正确的结果。 为了提高效率，暴力破解一般会使用带有字典的工具来进行自动化操作。

​ 理论上来说，大多数系统都是可以被暴力破解的，只要攻击者有足够强大的计算能力和时间，所以断定一个系统是否存在暴力破解漏洞，其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞，一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略，导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括：

​ 1.是否要求用户设置复杂的密码；
​ 2.是否每次认证都使用安全的验证码（想想你买火车票时输的验证码～）或者手机otp；
​ 3.是否对尝试登录的行为进行判断和限制（如：连续5次错误登录，进行账号锁定或IP地址锁定等）；
​ 4.是否采用了双因素认证；

1. 基于表单的暴力破解

打开bp，抓包，发送到Intruder模块：

进入Intruder界面，我们对我们要进行破解的数据段进行标记（所有的攻击都是针对于标记内容的）并且选择相应的Attack type（攻击类型）（burp suite的四种 attack type（攻击类型））

们要破解username和password，就应当选取Cluster bomb的攻击方式，在payloads中上传我们的字典，首先在payload set 1中上传username的字典，再选取payload set 2上传password的字典。考虑到用户名和密码有特殊符号的情况，这里把URL-encode去除勾选。

然后点击start attack开始爆破，最后根据爆破的长度结果，筛选出正确的用户名和密码。（爆破的原理就是将字典中的数据一次次的进行不同的组合发送响应，根据返回的报文长度来判断结果是否正确，正确的返回报文和错误的返回报文是不同的。）

成功登录

2.验证码绕过（on server）

​ 首先我们对各种情况的返回进行观察，当我们输入错误的账号密码和错误的验证码时，它提示我们验证码输入错误。输入错误的账号密码，但是正确的验证码时， 它又提示我们用户名和密码不存在，并且每次提交登录请求后验证码都会刷新。

那有没有一种可能，如果我不刷新网页或者提交请求，验证码就会一直有效，我也就可以通过上一关的步骤来进行爆破。

​ 我们来验证一下，我们将随便一个包send to repeater，将验证码改完现在页面中显示的值，send，在response中查找一下username or password， 有这段数据，证明现在这个二维码是正确的。

我们不改动现在的验证码，再把密码改一下，再次send，发现返回的还是username or password is not existed，说明验证码还是对的。

这就说明我们的猜想是正确的，只要页面不刷新，我们不提交请求，验证码就可以在bp中多次使用，那我们直接在repeater中把现在的请求包send to intruder，重复上一关的步骤，果然还是这个用户名和密码。

代码分析：

if(isset($_POST['submit'])) {if (empty($_POST['username'])) {$html .= "<p class='notice'>用户名不能为空</p>";} else {if (empty($_POST['password'])) {$html .= "<p class='notice'>密码不能为空</p>";} else {if (empty($_POST['vcode'])) {$html .= "<p class='notice'>验证码不能为空哦！</p>";} else {
//              验证验证码是否正确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();//虽然前面做了为空判断,但最后,却没有验证验证码!!!}}}
}

我们查看一下源代码我们可以看到在代码判断验证码是否正确后，并没有销毁之前的验证码，这就让我们钻了空子， 并且我们在页面F12就可以在cookie中看到所有输入过的验证码，这说明在生成验证码的时候，制作者还多此一举的把验证码作为cookie的一部分发送给了客户端，那就算在判断阶段有销毁步骤，攻击者也可以通过document.cookie获取到验证码从而实现爆破。

验证码绕过（on client）

​ 老规矩，我们先观察。

​ 我们输入正确的验证码，错误的用户名和密码。提示的是用户名和密码不存在

​ 我们再输入错误的验证码和错误的用户名和密码。这次是弹窗显示验证码错误，错误的用户名和密码也没有像之前一样清除。

F12检查网页源代码，我们可以找到前端校验验证码的js脚本

既然是前端检测，那我们只需要用bp发送请求报文绕过前端就行了，依旧是重复第一步的步骤。（这里就不赘述了）捎带一提，任何前端的校验对于防止安全攻击都是靠不住的！

token防爆破？

​ 先观察，这一关没有了验证码，输入错误的用户名和密码还是会提示不存在。

既然和token相关那我们就用不一样的值登陆两次看看抓到的报文有什么不同，可以发现确实两次的token不同。

右键发送给测试器，先取消所有标记，然后给密码和token单独设置标记。

• 设置变量。这里为了减少攻击次数，可以把账号修改为 admin，只将密码和 token设置成变量，攻击类型选择 Pitchfork，因为每次的密码和 token需要同时替换，而不能组合使用。

• 设置宏定义。点击 settings选项，下拉找到 Grep Extract栏，点击Add，在弹出的窗口中点击 Refetch response发一次包并获得返回数据，在下面输入栏处输入 token，找到返回的 token值

• 选中 token值并复制，同时在选中的情况下点击OK。然后将线程数设置为1，并在最下方 Redirections重定向栏，选择 Always

最后将前面复制的 token值粘贴在下方文本框

• 最后开始攻击，并根据返回长度判断是否爆破成功即可

总结

• 设计安全的验证码：安全的流程+复杂可用的图形
• 对认证错误的提交进行计数并给出限制，如5次连续密码错误时锁定该IP一定时间
• 必要情况下使用双因素认证
  回长度判断是否爆破成功即可

[外链图片转存中…(img-hOwNxitH-1694785315207)]

总结

• 设计安全的验证码：安全的流程+复杂可用的图形
• 对认证错误的提交进行计数并给出限制，如5次连续密码错误时锁定该IP一定时间
• 必要情况下使用双因素认证
• token防爆破：一般做法是将 token以 type="hidden"的形式输出在表单中，在提交认证时一起提交，并在后台对其进行校验。但由于 token值输出在了前端源码中，容易被获取，因此也就失去了防暴力破解的意义。