来到Web安全的领域，大多数人很快就会联想到许多漏洞，像SQL注入、XSS漏洞、CSRF漏洞、SSRF漏洞等，而在Web安全的开篇当中，我将从什么是Web安全说起，到工具Burpsuite的使用，并分享一些简单的暴力破解漏洞。

一、什么是Web安全

Web安全（Web Security） 是指：

保护网站、Web应用和服务器免受攻击、入侵、篡改、数据泄露、服务中断等威胁的一系列安全措施与技术。

简单说，就是：

让网站“能访问、访问的人是对的、看到的数据是安全的”。

Web安全的核心，是防止“数据被盗、被改、被滥用”，并保证网站可靠运行。

二、为什么暴力破解漏洞属于后端漏洞

1、什么是“前端”，什么是“后端”

前端：用户直接接触的 “门面”

• 核心定位是用户界面与交互体验，运行在浏览器或客户端。
• 主要技术包括 HTML（搭建页面结构）、CSS（美化页面样式）、JavaScript（实现交互效果）。
• 比如网页的布局、按钮点击反馈、动画效果等都属于前端范畴。

后端：隐藏在背后的 “支撑系统”

• 核心定位是数据存储、业务逻辑处理，运行在服务器端。
• 主要技术包括各类编程语言（Java、Python、Node.js 等）和数据库（MySQL、MongoDB 等）。
• 比如用户登录验证、数据查询与修改、接口提供等都属于后端工作。

2、暴力破解漏洞

关于对暴力破解漏洞属于前端还是后端的界定，有时候会让人产生误解，其根本原因是暴力破解漏洞本身是因为配置问题所导致的，而这样的配置缺陷既发生在前端，又发生在后端。

我们在访问网站的时候，可以直接打开网站前端的源代码，倘若开发者心存侥幸，即便设置了验证码这样的防爆破机制，但仅仅用JS写在前端（这样的情形在后文中会出现实例），这样就会导致有过Web安全基础的用户可以很快做出爆破，这就属于网页前端的不当配置。而在网页后端，开发者在配置验证码的时候，忘记设置验证码的有效持续时间，或者设置持续时间过长，这样的配置在某些用户的不断尝试中仍然可以被发现漏洞的存在，在一个很短的时间内就有可能暴力破解成功。

因此单纯看待发现该漏洞的源码位置并不能界定它属于前端还是后端，但是换个角度想，无论是验证码配置也好，还是token配置也罢，这些安全配置都属于后端的工作，只是有些配置在前端可以找到突破口而已，所以，暴力破解属于一个后端漏洞。

为什么要界定暴力破解属于前端还是后端呢？只有在这样的思考之下，我们对漏洞的理解才会加深，我们后期对于该漏洞的利用思路才会更牢靠。

三、暴力破解漏洞靶场练习

（说明：该漏洞练习均在个人安全设备和Pikachu靶场安全环境下进行）

1、基于表单的暴力破解

打开pikachu漏洞练习平台——基于表单的暴力破解

直观来看是一个登录界面，需要输入用户名和密码，这边我们先随便输入一个用户名和密码，观察一下网站的进一步响应：

出现的响应是——username or password is not exists~（记住这个响应）

接下来我们打开Burp suite工具，在proxy（代理）功能中对Pikachu靶场进行抓包：

Burp suite可以在我们的请求到达服务器之前拦截我们主机发出的请求，这里展示出了我们发出的请求包，接下来我们要对该登录界面的账户密码进行暴力破解，我们需要将我们拦截的包发送到intruder（侵入）功能栏中：

这里需要我们自行选择工具类型：

• Sniper（狙击手模式）
  • 特点：使用一组 payload 集合，一次只替换一个 payload 位置。假设标记了两个位置 “A” 和 “B”，payload 值为 “1” 和 “2”，那么它攻击会形成的组合为：A 位置为 1 时 B 位置不替换、A 位置为 2 时 B 位置不替换、A 位置不替换时 B 位置为 1、A 位置不替换时 B 位置为 2。
  • 适用场景：适用于对单个参数进行单独测试的场景，例如已知用户名，对密码字段进行猜测攻击。
• Battering ram（攻城锤模式）
  • 特点：同样只使用一个 payload 集合，但每次攻击都会同时替换所有 payload 标记位置。比如有两个位置 “A” 和 “B”，payload 值为 “1” 和 “2”，则攻击组合为：A 位置和 B 位置都为 1、A 位置和 B 位置都为 2。
  • 适用场景：当请求要求多个字段同时使用相同的值时可以使用，例如某些系统中要求用户名和密码字段输入相同的值进行测试。
• Pitchfork（草叉模式）
  • 特点：允许使用多组 payload 组合，在每个标记位置上遍历所有 payload 组合。假设有两个位置 “A” 和 “B”，payload 组合 1 的值为 “1” 和 “2”，payload 组合 2 的值为 “3” 和 “4”，则攻击模式为：A 位置为 1 且 B 位置为 3、A 位置为 2 且 B 位置为 4。如果两个 payload 行数不一致，取最小值进行测试。
  • 适用场景：当请求要求多个字段同时有值，且每个参数的值不同时适用。
• Cluster bomb（集束炸弹模式）
  • 特点：会对 payload 组进行笛卡尔积运算。还是以上面的例子来说，如果用集束炸弹模式进行攻击，除了基线请求外，会有四次请求，分别是：A 位置为 1 且 B 位置为 3、A 位置为 1 且 B 位置为 4、A 位置为 2 且 B 位置为 3、A 位置为 2 且 B 位置为 4。
  • 适用场景：当需要对多个参数进行全面的组合测试时使用，例如同时对用户名和密码进行暴力破解，且用户名和密码都有各自的字典。

这里我们使用Cluster bomb模型，这样的效率会相对显著一些，选择好工具类型后我们需要进行payload设置：

这边payload类型我选择简单列表的原因在图片里已有说明，这样的效率会相对降低，但是并不影响后续的爆破，紧接着我们来配置资源池：

本次展示所用的是Burp suite 专业版，没有并发限制，由于我们的字典相对较大，所以把并发数量调到200，提高我们的爆破效率，值得注意的是有的网站配置有并发请求的限制，所以我们在保证自身安全（不被暴露）的情况下进行最有效率的配置，本次实验是在靶场上进行，所以不用考虑这么多。

接下来配置检索匹配机制，这一点特别说明，因为字典的庞大，我们没有办法在爆破结束后第一时间发现正确的用户名和密码，所以需要配置一个检索条件，这里直接选用我之前让大家特别记忆的一句话：

username or password is not exists~ （登录失败的响应）

大家可以看到图片上有一句话，就是响应的字节长度也有区别，大家可能觉得不需要去设置这么长的检索条件，但在实践的过程中，由于字典过大的因素，会出现很多不同字节长度的响应，这样就无法进行快速的检索了。

在所有配置结束以后，我们就可以进行攻击了：

在我们的检索之下，很快就找到了第一个用户名和登录密码信息，我们在网站给出的响应中可以看到我们登录成功了。

基于表单的暴力破解这一题目是一个没有验证码的不安全配置，因此我们利用工具就可以轻而易举的爆破出该网站的登录信息，接下来就是和验证码相关的暴力破解漏洞实践。

2、验证码绕过(on client)

这次的攻击环境里有了验证码的设置：

但是即便有了验证码的配置，就像上文中提到的那样，仍然会有安全配置问题，我们打开该界面的源码：

很容易找到了一个JS的验证码配置，这不就说明该验证码机制写在前端吗？换句话说，没有后端的程序来检验验证码是否正确，这样的验证码形同虚设。

为了验证上述猜想，我们仍然使用Burp suite进行抓包：

这里我们看到自己发出的请求中包含有验证码这一项，这样我们就可以进行发送尝试，去判断该验证码是否形同虚设，我们将请求包发送到重放器中：

直接将验证码设置为空，发送请求，发现服务器给我们的响应成功绕过验证码，来到了用户名密码不存在的报错，这样就完美验证了“该验证码形同虚设”这句话。接下来我们进行爆破：（这次注意一下进行payload的位置，不含验证码这一项）

重复第一题的配置，我们爆破成功！

3、验证码绕过(on server)

常见不安全的on server问题，在上文中也有提及，就是验证码的过期问题、验证码的校验不严格以及验证码过于简单的问题。

这个题目的验证码配置从界面上就可以感受到，和上一个题目是有区别的，我们打开该界面的源码，查找一下是否有和上一题一样的前端配置问题：

我们找不到前端源码中关于任何验证码的配置，这就说明验证码配置在后端，这时我们无法直接看到验证码的相关配置，因此我们需要做出尝试：

第一次尝试：输入错误的验证码

第二次尝试：输入正确的验证码

第三次尝试：验证码不发生改变，改变用户数据，再次提交请求，看验证码是否刷新

这时我们发现，验证码没有失效，而是继续输出用户名密码错误的报错，这就说明这个验证码在后台的配置不安全，可能不会过期，也可能有效期很长，在验证码有效的期间内我们就可以做很多的事情，接下来就进行爆破吧：

payload和上面的题目用一样的配置，把验证码部分保持该正确验证码不变，照常进行爆破：

结果——爆破成功！

对于这样情形的题目，我们进行一下复盘，这里通过该网站写在后端的源码说明：

这是后端的验证码配置，很明显可以看出该验证码在提示完输入错误，也就是验证流程结束以后，并没有销毁该验证码或者对该验证码有效期的配置，这样的疏忽配置可以说和上道题的侥幸心理无异，都会使验证码形同虚设，起不到防止爆破的作用。

4、Token防止爆破

在这个情景之下，所谓Token的配置其实就是为了防止多次并行的爆破尝试而设置的一种随机编码生成机制，好让每一条请求都有后端给它的唯一标识，而这样的标识应该在用户看不见的地方。但是仍有不安全配置的token，直接以编码的样式呈现在用户的眼前，也就是这道题的情景：

这样的token配置和验证码的错误配置一样，形同虚设，我们可以根据已知的Token在payload设置中将token的形成过程模拟，并正常进行爆破。

最后我把Token对于密码爆破的正确理解以可视化的方式展示一下：

关于Token在后续的Web漏洞篇也会集中讲解。

Web安全的开篇到这里结束，暴力破解漏洞虽然简单，但是依然能反映我之前在文章中提及的一句话：

任何安全机制的正确性都取决于配置，而绝不是机制本身！