本文共 2277 字，大约阅读时间需要 7 分钟。
Pikachu 官方对暴力破解的介绍如下：
我忍不住想吐槽一下他们的“brute force”拼错了(～￣▽￣)～
作为一颗小白菜，我没有字典。但是我知道一个下载字典的好地方，那就是github！在github搜索“字典”，可以找到好多好多字典。然而，github上的很多资源下载速度很慢，实在忍不了。
后来我发现，可以在github找到心仪的字典后，通过gitee下载。这是因为gitee的下载速度更快，操作也更友好~（虽然并不是每个字典都能在gitee上找到(*>﹏<*)′）
不过，对于这个靶场来说，没用字典也没关系。这个靶场主要教怎么绕过限制，特别是“基于表单的暴力破解”关卡点，提示里面已经告诉了我有三个用户密码。我可以用这些加上几个假字典来体验一下效果。
打开Burps Suite，一边随便输入一个用户名密码，观察回显，一边用Burps Suite抓包。
把下面这个带username和password参数的报文发送到 Intruder。
在Intruder模块中设置：
username和password的值。Cluster bomb（关于四种Attack Type的具体效果可以参考下文）。由于Position设置了两个，Attack Type选了Cluster bomb，因此需要两个字典。Payload的效果是两个字典条目的组合，数量是两个字典条目数的乘积。
按照以下步骤操作：
simple list，加载用户名字典。simple list，加载密码字典。点击Start attack开始爆破。完成后，按长度排序，果然能找到那三个用户名密码（排序前的前三个，长度和其他都不一样的）。
观察一下，用户名和密码输入错误值时，返回的提示是“验证码错误”；当验证码是正确值时，返回提示是“用户名或密码不存在”。
发现网页没刷新时，验证码可以多次使用。将刚刚试验的随便一个包发送到Repeater。
将上面提到的请求包发送到Intruder，配置方式与第一关相同。
完成后，按长度排序，果然能找到那三个用户名密码（排序前的前三个，长度和其他都不一样的）。
为什么会产生这种情况呢？仔细查看本关的主要代码，发现验证完验证码后并没有销毁$_SESSION['vcode']，所以才导致$_SESSION['vcode']可以被多次使用。
再查看生成$_SESSION['vcode']的代码，发现应该去../../inc/showvcode.php找。找到后发现只是简单地调用vcodex()生成$_SESSION['vcode']。vcodex()在function.php里，没什么可说的。
此外，还发现有一个画蛇添足的步骤是把验证码作为cookie的一部分传给客户端。这样即使服务器销毁了$_SESSION['vcode']，攻击者也可以通过document.cookie获取到验证码，实现自动化暴力破解。
Chrome浏览器的F12可以在Application的Cookie中看到这个验证码。
观察一下，用户名和密码输入错误值时，返回的提示是“验证码错误”；当验证码是正确值时，返回提示是“用户名或密码不存在”。
右键查看网页源代码，发现果然前端有检验验证码的js脚本。
将Burps Suite的Proxy模块抓到的这个报文发送到Intruder。
按照以下步骤操作：
simple list，加载用户名字典。simple list，加载密码字典。点击Start attack开始爆破。完成后，按长度排序，果然能找到那三个用户名密码（排序前的前三个，长度和其他都不一样的）。
事实再次证明，任何前端的校验对于防止安全攻击都是靠不住的！
首先还是观察~这关没有验证码，用户名或者密码输错会提示“用户名或密码不存在”。
由于和token有关，我们用不一样的值登录两次，观察Burps Suite抓到的报文有什么区别。
将Proxy模块抓到的两次登录报文发送到Comparer对比，确实两次的token不一样。
将Proxy模块抓到的报文发送到Repeater，尝试以下方法：
csrf token error。hidden的token标签，value和请求报文的token不一样，应该是下一个报文的token。将请求中的token值改为响应中的token值，再次发送，返回提示“用户名或密码不存在”，并且返回了下一次的token值。
根据以上结果，下一次请求需要携带的token就是上一次响应中hidden字段的值。
看来token对防暴破没啥用，因为总要让客户知道下一次用什么token的，因此总能被自动化工具获取。
token的存在主要还是针对CSRF的。
总之，像这样的验证方式根本无法阻止自动化工具突破。
转载地址：http://iqun.baihongyu.com/