目录

一、官方概述

二、小白菜的通关

第一关  基于表单的暴力破解

第二关  验证码绕过(on server)

1、绕过步骤

2、一点思考

第三关  验证码绕过(on client)

1、绕过步骤

2、一点思考

第四关  token防爆破?

1、绕过步骤

2、一点思考

---

一、官方概述

pikachu官方对暴力破解的介绍如下，我要嘲笑一下他brute拼错了(～￣▽￣)～

二、小白菜的通关

暴力破解，首先得有字典。

作为一颗小白菜，我，没有字典。。但是我知道一个下载字典的好地方，那就是大名鼎鼎的github！

在github搜索“字典”，就可以搜到好多好多字典。。然而，github上的东西常常下载不下来，或者下载非常缓慢，不能忍。。

后来发现，可以在github里找到心仪的字典之后，拿字典的名字到gitee上搜索和下载~嗖~就下载好了q(≧▽≦q)  （不过不是每个都能搜到`(*>﹏<*)′）

（其实对于这个靶场来说，没有字典也没关系，这靶场主要是教怎么绕过限制，“基于表单的暴力破解”关卡点一下提示就会告诉你有哪三个用户密码，用这几个再加几个错误的做个假字典体会下效果就好。由于用正经字典爆破组合太多，所以我就是这样做哒~）

下面就开始正式闯关吧~

第一关  基于表单的暴力破解

请出burpsuite，一边随便输入个用户名密码并观察回显，一边burpsuite抓包

把下图这个带username和password参数的报文send to intruder

然后在intruder模块这样设置

首先position选username的值和password的值，然后Attack Type选Cluster bomb（关于4种Attack Type分别是什么效果可以参见burp suite的四种 attack type（攻击类型））

接下来由于position设置了两个，Attack Type选了Cluster bomb，因此，需要两个字典，payload效果是两个字典条目的组合，数量是两个字典条目数的乘积。

按顺序，第一个字典像下图这样选simple list并把用户名字典load进来

第二个字典像下图这样选simple list并把密码字典load进来

考虑到用户名和密码有特殊字符的情况，这里把URL-encode去勾选

按start attack开始爆破，完成后结果按Length排序，果然是那三个用户名密码（排序的前三个，Length和其他都不一样的）。

第二关  验证码绕过(on server)

1、绕过步骤

首先观察一下，用户名和密码输入错误值，当验证码是错误值时，返回结果如下，提示验证码错误

用户名和密码输入错误值，当验证码是正确值时，返回结果如下，提示用户名或密码不存在

并且每次提交都会自动刷新验证码

那有没有可能，我只要不在网页上点Login，不刷新网页，网页当前显示的验证码就一直有效呢？

来试试~

把刚刚试的随便一个包send to repeater

改成当前网页显示的验证码，send，发现response中提示的是用户名或密码不存在，说明验证码是对的

还是这个验证码，把密码改一下，send，发现response中提示的还是用户名或密码不存在，说明验证码还是对的

这就说明之前的猜想是正确的，只要网页没刷新，验证码在burp suite中可以多次使用

直接从repeater中把上图的请求包send to intruder，和上一关一样配置intruder（截图如下，具体解说见上一关）

按start attack开始爆破，完成后结果按Length排序，果然是那三个用户名密码（排序的前三个，Length和其他都不一样的）。

2、一点思考

为什么会产生这种情况呢？

先看看本关的主要代码

在下图的38行也提示了，本关在验证完验证码之后没有把$_SESSION['vcode']销毁，所以才导致$_SESSION['vcode']可以被多次使用

再看一下生成$_SESSION['vcode']的代码

通过下图知道代码应该去../../inc/showvcode.php找

找到../../inc/showvcode.php之后发现就是session_start()然后调用vcodex()去生成$_SESSION['vcode']

vcodex()在function.php里面，没什么可说的，就不贴出来了。

上图这段代码里面还有个画蛇添足的步骤是把验证码作为cookie的一部分传给客户端了。。那就算验证结束有销毁步骤，其实攻击者也可以通过document.cookie获取到验证码从而实现自动化暴力破解。

chrome浏览器F12可以在Application的Cookie中看到这个验证码

第三关  验证码绕过(on client)

1、绕过步骤

还是先观察

用户名和密码输入错误值，当验证码是正确值时，返回结果如下，提示用户名或密码不存在

用户名和密码输入错误值，当验证码是错误值时，有弹框提示验证码错误，之前对用户名或密码的提示也没有清除

那根据上面两张图，特别是验证码错误时有弹框这点，非常怀疑用户名和密码是在后端验证的，但验证码是在前端验证的。

右键 查看网页源代码，发现果然前端有检验验证码的js脚本

到目前为止一切就清楚啦，既然是前端检测，那直接用burpsuite发请求报文绕过前端就可以了

把burpsuite的proxy模块抓到的这个报文send to intruder

然后按照下图配置intruder，具体解释见第一关

按start attack开始爆破，，完成后结果按Length排序，果然还是那三个用户名密码（排序的前三个，Length和其他都不一样的）。

2、一点思考

事实再次证明，任何前端的校验对于防止安全攻击都是靠不住的！

第四关  token防爆破?

1、绕过步骤

首先还是观察~这关没有验证码了，用户名或者密码输错会提示用户名或密码不存在

那既然和token有关，我们用不一样的值login两次看看burpsuite抓到的报文有啥区别？

把proxy模块抓到的两次登录的报文send to comparer对比一下，确实两次的token不一样

把proxy模块抓到的报文send to repeater，操作操作，观察一下有什么办法突破：

（1）先尝试不改动token，直接重放，response中提示  csrf token error

（2）尝试删除token，response中什么返回结果都没有

（3）虽然前面两条路死了，但是尝试的时候发现response中网页源代码有一个type为hidden，name为token的input标签，value和request报文的token不一样，应该是下一个报文的token。

那试一下把request中的token值改为response中的token值，再次send，返回了提示用户名或密码不存在，并且返回了下一次的token值（下图request中的token不是上图response中的token是因为中间又发了一个报文，导致两张图没有连上）

根据以上结果，下一次request需要携带的token就是上一次response中html代码中的隐藏字段值，也就是说request中的token是可以从上一个response中提取的

那么还是可以暴力破解，只不过配置稍微复杂一点：

首先position除了username和password再增加token，此外要注意Attack type选Pitchfork（payload一一对应，数量为最少的payload的数量）。.这里为啥要选Pitchfork而不能选Cluster bomb，尝试一下就知道了`(*>﹏<*)′（剧透：因为Cluster bomb是三组payload排列组合，一个token用好几次显然不行）

由于前面使用的用户名和密码payload列表都是适用于Cluster bomb的，而Pitchfork对payload的要求可能更高一些（需要提前整理好对应关系），所以我这里暗中把用户名和密码payload列表改了一下。

接着第一和第二个payload按照前几关那样设置

第三个payload type设置为Recursive grep

上图这个payload options是在哪里设置的呢？就是下图这里

小框框勾选上，然后点add，弹出来的窗口要是下面啥也没有就点一下Refetch response，然后找到response中的token，双击value后面的值，上面define start and end的地方就会自动生成正则表达式啦

然后点OK就行

确认上面这个设置之前我觉得保险起见应该在网页源代码里面观察一下有多少符合正则表达式的位置

从下图来看就这一个地方符合，那就妥了

此外还有一个需要注意的地方是线程要设置为1，这是因为每次都要用上次response中返回的token，多线程就会乱套了。

按start attack开始爆破，，完成后结果按Length排序，果然还是那三个用户名密码（排序的前三个，Length和其他都不一样的）。

2、一点思考

看来token对防暴破没啥用，因为总要让客户知道下一次用什么token的，因此总能被自动化工具获取。

token的存在主要还是针对CSRF的。

 

如有疑问欢迎留言讨论，如有错误欢迎指正