一、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
值输出在了前端源码中,容易被获取,因此也就失去了防暴力破解的意义。