Pikachu靶场实战：SQL注入漏洞深度解析与防御指南（上篇）

1. 从零开始：为什么SQL注入依然是头号威胁？

如果你刚接触网络安全，可能会觉得SQL注入是个“老掉牙”的话题，都2024年了，怎么还在讲这个？我刚开始也是这么想的，直到我亲手用Pikachu靶场做实验，才发现事情没那么简单。SQL注入之所以能常年稳居OWASP Top 10的前列，不是因为它技术多新，恰恰是因为它太“经典”、太“有效”了。很多开发者在写代码时，一个不小心，就会留下让攻击者长驱直入的后门。

简单来说，SQL注入就是攻击者通过在Web应用的输入框（比如登录框、搜索框）里，输入一些精心构造的SQL代码片段。如果网站的后台程序没有对用户的输入进行严格的检查和过滤，就会把这些恶意代码当作正常的SQL语句的一部分去执行。想象一下，你本来只是想查一下自己的订单，结果攻击者输入一段代码，直接把整个数据库的用户名和密码都给“问”出来了，是不是很可怕？

Pikachu靶场就是一个专门为学习这些漏洞而设计的“练功房”。它把各种类型的SQL注入场景都模拟好了，环境纯净，没有法律风险，让你可以放心大胆地去“攻击”，去理解漏洞是怎么产生的，以及如何防御。我当年就是靠着在类似靶场里一遍遍实操，才真正把书本上的理论变成了肌肉记忆。所以，无论你是想转行做安全，还是后端开发想提升代码安全性，跟着我一起把Pikachu靶场里的SQL注入关卡过一遍，绝对会让你有脱胎换骨的感觉。

在开始之前，你需要准备好两样东西：一个是安装好的Pikachu靶场（通常是一个PHP环境，集成在XAMPP或Docker里），另一个就是浏览器和一个趁手的抓包工具，比如Burp Suite。别怕，这些工具的安装和使用，我们后面都会详细讲到。咱们的目标不是死记硬背几个注入语句，而是真正理解每一种注入背后的原理和逻辑，这样你以后无论遇到什么奇怪的网站，都能一眼看出门道。

2. 实战数字型注入：从抓包到拖库的完整链条

数字型注入可以说是最“直白”的一种注入类型了。它通常发生在后端程序根据用户输入的ID来查询数据库时，比如 SELECT * FROM news WHERE id = $id。如果这个 $id 变量是直接从用户输入（比如URL参数 ?id=1 或POST表单）获取，并且没有经过任何处理，那漏洞就产生了。

2.1 环境搭建与初步探测

首先，我们启动Pikachu靶场，找到“SQL注入”模块下的“数字型注入（POST）”关卡。页面通常是一个简单的输入框，让你输入一个用户ID来查询信息。我们输入“1”并提交，页面会显示ID为1的用户信息（比如用户名、邮箱）。看起来一切正常，对吧？但魔鬼藏在细节里。

这时候，打开你的Burp Suite，确保代理已经设置好（浏览器指向Burp的监听端口，比如8080），然后开启拦截功能。在靶场页面再次提交查询，你会发现Burp抓到了一个POST请求。这个请求的包体里，包含了类似 id=1&submit=查询 这样的数据。这就是我们的突破口——id 参数。

2.2 核心攻击步骤详解

抓到包之后，我们右键把它发送到 Repeater 模块。Repeater就像一个可以反复调试请求的“回放器”，是我们手工注入测试的利器。接下来，就是经典的“四步走”：

第一步：判断注入点并确认列数 我们把 id 的值从 1 改成 1 order by 10 #。这里的 order by 是用来对查询结果排序的，后面的数字代表按第几列排序。我们故意写一个很大的数字10，然后发送请求。不出意外，页面会报错，提示大概意思是“未知的列 ‘10’”。这说明实际的查询结果没有10列那么多。

我们逐步减小这个数字，比如改成 1 order by 5 #，再发送。如果还报错，就继续减小，直到 1 order by 3 # 时，页面可能依然报错，但错误信息变了，或者页面返回异常。当我们尝试 1 order by 2 # 时，页面正常返回了数据。这说明，后端那条SQL查询语句，最终返回的列数就是 2列。这一步非常关键，它决定了我们后续 union select 语句能拼接多少列。

第二步：寻找数据回显位 知道了列数，我们就能用 union 来拼接我们自己的查询了。把Payload改成：1 union select 1,2 #。union 的作用是联合查询，它要求前后两个 SELECT 语句的列数必须一致。所以我们用两个数字 1 和 2 来占位。发送请求后，仔