别再死记硬背了！用Pikachu靶场图解Web安全核心漏洞原理（XSS/CSRF/SQL注入对比）

用Pikachu靶场图解Web安全三大核心漏洞：XSS/CSRF/SQL注入实战对比

当你第一次接触Web安全时，是否曾被XSS、CSRF和SQL注入这些术语搞得晕头转向？它们看起来都很相似，却又各具特点。今天，我们就通过Pikachu靶场这个绝佳的学习平台，用可视化的方式拆解这三大经典漏洞的本质区别。不同于枯燥的理论讲解，我们将亲手触发每种漏洞，观察浏览器、服务器和数据库的实时反应，就像在实验室里做解剖一样清晰明了。

想象一下，XSS就像在别人家的留言板上偷偷贴恶意小广告，CSRF则是伪造你的签名去银行转账，而SQL注入则如同用万能钥匙直接撬开数据库大门。通过Pikachu靶场的实战环境，我们不仅能理解这些生动的比喻，更能掌握它们的技术实现原理和防御方法。下面，就让我们开启这场Web安全的探索之旅。

1. XSS：客户端脚本的"恶意涂鸦"

1.1 反射型XSS：一次性的恶作剧

在Pikachu靶场的反射型XSS关卡中，当我们输入普通文本如"hello"时，页面正常显示。但当我们输入<script>alert('Hacked!')</script>时，浏览器突然弹窗——这就是典型的反射型XSS攻击。

关键特征对比表：

特性	反射型XSS	存储型XSS	DOM型XSS
持久性	临时性，随URL消失	永久存储于服务器	不依赖服务器
触发方式	需要诱骗点击	访问被感染页面	前端JS处理不当
危害范围	单个用户	所有访问者	依赖页面逻辑

在开发者工具中可以看到，恶意脚本被直接插入到HTML响应中：

<div id="result"> <script>alert('Hacked!')</script> </div>

1.2 存储型XSS：网站上的"慢性毒药"

进入Pikachu的留言板功能，当我们提交一段恶意脚本后，刷新页面发现弹窗依然存在——这说明脚本已被永久存储在数据库中。更可怕的是，其他用户访问该页面时也会中招。

典型防御方案：

• 输入过滤：移除<script>等危险标签
• 输出编码：将特殊字符转为HTML实体
• CSP策略：限制脚本执行来源

提示：现代前端框架如React/Vue已内置XSS防护，但开发者仍需警惕dangerouslySetInnerHTML等特殊场景

2. CSRF：会话劫持的"隐身术"

2.1 CSRF攻击的本质：借刀杀人

在Pikachu的CSRF关卡中，登录用户lili后，攻击者构造一个隐藏表单：

<form action="http://靶场地址/csrfget/modify.php" method="GET"> <input type="hidden" name="sex" value="hacked"> <input type="hidden" name="phonenum" value="13333333333"> <input type="submit" value="点击领红包"> </form>

当用户点击按钮时，个人信息在不知情的情况下被修改——这就是CSRF的典型攻击流程。

2.2 与XSS的关键区别

虽然都涉及跨站，但它们的攻击维度完全不同：

维度	XSS	CSRF
目标	窃取用户数据	冒充用户操作
位置	漏洞发生在受信网站	利用受信网站的权限
防御	输入输出过滤	Token验证/Referer检查

实战检测方法：

1. 使用Burp Suite生成CSRF PoC
2. 观察请求是否依赖会话cookie
3. 检查关键操作是否有Token验证

3. SQL注入：数据库的"万能钥匙"

3.1 数字型注入：最直白的攻击

在Pikachu的数字型注入关卡，输入1 or 1=1时，系统返回所有用户信息——这是因为构建的SQL语句变为：

SELECT * FROM users WHERE id=1 or 1=1

这个简单的例子揭示了SQL注入的核心：通过用户输入改变查询逻辑。

3.2 不同类型SQL注入对比

类型	示例输入	危险操作
联合查询	1' UNION SELECT 1,user(),3#	获取数据库信息
布尔盲注	1' AND substring(database(),1,1)='p'#	逐字符猜解
时间盲注	1' AND IF(1=1,SLEEP(5),0)#	通过延迟判断
堆叠查询	1'; DROP TABLE users#	执行多语句

防御矩阵：

防御层	具体措施	有效性
输入层	参数化查询	★★★★★
架构层	WAF防护	★★★☆☆
运维层	最小权限原则	★★★★☆

4. 综合对比与防御实践

4.1 三大漏洞的"攻击路径图"

graph TD A[攻击者] --> B[XSS: 客户端执行] A --> C[CSRF: 伪造请求] A --> D[SQL注入: 服务器查询] B --> E[窃取Cookie/会话] C --> F[未授权操作] D --> G[数据泄露/破坏]

4.2 防御措施实战演示

XSS防御代码示例：

// 输出编码 function xss_clean($data) { return htmlspecialchars($data, ENT_QUOTES, 'UTF-8'); } echo '<div>'.xss_clean($user_input).'</div>'; // CSP头设置 header("Content-Security-Policy: default-src 'self'");

CSRF Token实现：

// 生成Token const csrfToken = crypto.randomBytes(32).toString('hex'); document.cookie = `csrf_token=${csrfToken}; SameSite=Strict`; // 验证Token app.post('/transfer', (req, res) => { if(req.cookies.csrf_token !== req.body.csrf_token) { return res.status(403).send('Invalid CSRF Token'); } // 处理业务逻辑 });

SQL注入防护：

# 使用参数化查询 cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,)) # ORM安全示例 User.objects.filter(id=user_id)

在Pikachu靶场的通关过程中，我深刻体会到安全防御需要多层次配合。比如防止SQL注入时，参数化查询能解决大部分问题，但结合预编译语句和最小权限原则会更可靠。而对付XSS，除了输出编码外，CSP策略就像给浏览器上了第二道保险。