SQL注入漏洞实战：从手工注入到参数化查询修复

1. 项目概述：一次典型的Web应用安全实战

最近在整理一些老旧的Web应用系统漏洞案例，发现很多开发者对SQL注入这类“古典”漏洞的防范意识依然不足。今天我们就来深入复现一个典型的案例：某微商城系统的goods.php文件存在的SQL注入漏洞。这个案例非常具有代表性，它涉及到一个常见的商品详情查询接口，由于对用户输入的参数过滤不严，导致了严重的数据库信息泄露风险。无论你是安全研究人员、渗透测试工程师，还是后端开发人员，理解这个漏洞的成因、利用方式以及修复方案，对于构建更安全的Web应用都至关重要。我们将从环境搭建开始，一步步分析漏洞原理，手工构造注入Payload，并最终探讨如何从根本上杜绝此类问题。整个复现过程旨在提供一个清晰、可操作的实战参考，而不仅仅是理论上的空谈。

2. 漏洞环境搭建与核心思路解析

2.1 目标系统与环境准备

本次复现的目标是一个使用PHP+MySQL开发的简易微商城系统。为了模拟真实环境，同时避免对线上系统造成影响，我们需要在本地或隔离的测试环境中搭建靶场。

我选择使用Docker来快速构建环境，这是目前最方便且可复现的方式。你需要准备以下组件：

1. Web服务器： 使用包含Apache和PHP的镜像，例如php:7.4-apache。选择PHP 7.4是因为很多遗留系统仍运行在此版本上，且其错误报告机制便于我们调试。
2. 数据库： 使用mysql:5.7镜像。MySQL 5.7同样是许多传统系统的标配。
3. 目标源码： 我们需要一个存在漏洞的goods.php文件及其相关的数据库结构。

操作步骤如下：首先，创建一个项目目录，在里面编写docker-compose.yml文件来定义服务。然后，将存在漏洞的PHP源码放置到Apache的网页根目录（例如./www/）。最后，导入数据库初始化脚本（sql/init.sql），这个脚本会创建商品表goods并插入几条测试数据。

注意： 务必确保测试环境与公网隔离。切勿在未授权的情况下对任何线上系统进行测试，这是法律和道德的底线。

2.2 漏洞代码与核心思路分析

让我们直接看存在问题的goods.php核心代码片段（经过简化和脱敏）：

<?php // goods.php $conn = mysqli_connect(“localhost”, “root”, “password”, “shop”); $id = $_GET[‘id’]; // 直接获取用户输入的id参数 $sql = “SELECT * FROM goods WHERE id = “ . $id; // 字符串拼接，危险！ $result = mysqli_query($conn, $sql); $row = mysqli_fetch_assoc($result); // … 后续显示商品信息 … ?>

漏洞的根源一目了然：程序直接从$_GET[‘id’]获取用户输入的参数id，未经任何过滤或转义，就直接拼接到了SQL查询语句中。这给了攻击者极大的操控空间。

攻击者核心思路： 我们的目标不再是获取id=1的商品信息，而是通过精心构造id参数的值，改变原SQL语句的逻辑，使其执行我们附加的恶意查询。例如，将id的值从1构造为1 OR 1=1。那么最终的SQL语句将变成：SELECT * FROM goods WHERE id = 1 OR 1=1由于1=1永远为真，OR条件会导致整个WHERE子句恒真，从而可能返回goods表中的所有数据，而不仅仅是id=1的那一条。这就是一次最简单的SQL注入攻击。

本次复现的深层目标不仅仅是实现“永真”攻击，我们将逐步深入，实现：1）联合查询注入，获取数据库中的其他敏感表（如用户表admin）的数据；2）基于布尔的盲注，在页面没有明显错误回显时，如何通过页面返回的差异（真/假）来逐位提取信息；3）基于时间的盲注，当页面返回内容没有任何差异时，如何通过引入延时函数来判断注入是否成功。我们将手工完成这一切，以彻底理解注入的每一个环节。

3. 手工注入实战：从信息探测到数据获取

3.1 初步探测与漏洞点确认

首先启动我们的靶场环境，访问http://localhost:8080/goods.php。正常情况下，它可能需要一个id参数，比如http://localhost:8080/goods.php?id=1。页面会显示ID为1的商品详情。

第一步，验证漏洞是否存在。我们尝试输入一个单引号’来破坏SQL语法：http://localhost:8080/goods.php?id=1’如果页面返回了数据库错误（如“You have an error in your SQL syntax…”），那么几乎可以确定存在SQL注入漏洞。错误信息是因为拼接后的SQL变成了… WHERE id = 1’，那个多出来的单引号导致了语法错误。

第二步，判断注入类型和闭合方式。数字型注入通常不需要闭合引号，而字符型注入需要。我们测试：

• id=1 AND 1=1-> 页面正常显示（条件真）。
• id=1 AND 1=2-> 页面可能显示为空或与之前不同（条件假）。 如果两者返回结果有差异，说明AND逻辑被成功执行，这强烈暗示是数字型注入，因为如果是字符型，参数很可能被引号包裹，如… WHERE id = ‘1 AND 1=1’，这会被当作一个整体字符串，AND不会生效。在我们的案例代码中，直接是id = “ . $id，没有引号，所以是典型的数字型注入。这一步的判断至关重要，它决定了我们后续Payload的构造方式（数字型无需考虑引号闭合，更为简单）。

3.2 联合查询注入获取数据库信息

联合查询（UNION）是效率最高的注入方式之一，它可以直接将我们想要查询的数据附加在原始查询结果之后返回到页面上。但使用UNION有几个前提需要先探明。

1. 确定原始查询的字段数。 UNION前后查询的列数必须相同。我们可以使用ORDER BY子句来探测。ORDER BY 1表示按第一列排序，如果该列存在，页面正常；ORDER BY 10如果报错，说明列数少于10。通过二分法，我们快速测试：id=1 ORDER BY 5-> 正常id=1 ORDER BY 6-> 错误 由此确定，原始SELECT * FROM goods查询返回5个字段。

2. 寻找数据回显点。 即便字段数对了，我们也需要知道页面的哪个位置会显示我们UNION查询的结果。我们构造Payload：id=-1 UNION SELECT 1,2,3,4,5这里将原查询的id设为-1（一个不存在的值），确保原查询不返回结果，这样页面显示的内容就全部来自我们的UNION查询。访问后，观察页面，原本显示商品名、价格的地方可能变成了数字2、3等。这意味着这些位置可以用来回显我们想要的数据。假设数字2和3的位置在页面上清晰可见。

3. 获取数据库名、表名、列名。 现在，我们可以把SELECT 1,2,3,4,5中的数字替换成我们想查询的数据库函数。

• 获取当前数据库名：id=-1 UNION SELECT 1,database(),3,4,5
• 获取所有表名：id=-1 UNION SELECT 1,group_concat(table_name),3,4,5 FROM information_schema.tables WHERE table_schema=database()information_schema是MySQL的系统数据库，存储了所有元数据。这条语句会查询当前数据库下的所有表名，并用group_concat()合并成一个字符串，显示在第二个字段的位置。假设我们发现了goods和admin两张表。
• 获取admin表的所有列名：id=-1 UNION SELECT 1,group_concat(column_name),3,4,5 FROM information_schema.columns WHERE table_schema=database() AND table_name=‘admin’假设返回了id,username,password。

4. 最终获取敏感数据。id=-1 UNION SELECT 1,username,password,4,5 FROM admin这样，我们就能在页面的第二、第三列位置直接看到后台管理员的用户名和密码（可能是明文或哈希值）。至此，通过联合查询注入，我们完成了从漏洞探测到完全拖库的全过程。

实操心得： 在实际测试中，ORDER BY探测列数时，如果页面错误信息被屏蔽，可以通过观察页面内容是否发生剧烈变化（如布局错乱、完全空白）来判断。联合查询注入能否成功，高度依赖于页面是否有明确的数据回显点。如果页面只显示“找到结果”或“未找到”，而不展示具体数据，那么联合查询将难以直接利用，需要转向盲注。

4. 盲注技术深入：当没有错误回显时

在很多实际场景中，开发者会关闭数据库错误提示（将display_errors设为Off），或者页面设计就是只返回“是/否”、“存在/不存在”，不会直接展示数据库查询结果。这时，联合查询注入就失效了。我们需要依靠布尔盲注和时间盲注。

4.1 布尔盲注原理与手工实践

布尔盲注依赖于页面对于输入不同Payload所返回内容的差异。这种差异可能很细微，比如一句话的不同、一个图片的加载与否、或者仅仅是“查询成功”与“查询失败”的文本区别。

攻击思路： 像猜谜一样，逐个字符地猜测数据。我们通过构造SQL条件，向数据库提问“这个数据的第一个字符是不是‘a’？”，然后根据页面的反应（真/假）来判断答案。

例如，我们想猜解当前数据库名的第一个字符。已知数据库名长度可以用length(database())=N来猜，假设我们已猜出长度为8。 接下来猜第一个字符的ASCII码。利用substring()或substr()函数截取字符串，以及ascii()函数获取ASCII码。 构造Payload：id=1 AND ascii(substr(database(),1,1)) > 100

• 如果页面返回正常（和id=1一样），说明条件为真，即第一个字符的ASCII码大于100。
• 如果页面返回异常（为空或错误状态），说明条件为假，即ASCII码小于等于100。 通过这种二分法（>100? >150? …），我们可以快速定位到准确的ASCII码，比如是112，对应字符‘p’。然后继续猜第二个字符：ascii(substr(database(),2,1)) > 100，如此反复。

手工过程极其繁琐，猜一个8位的数据库名就需要几十次请求。但这正是理解盲注本质的关键。在实际利用中，这个过程会通过编写Python脚本自动化完成。脚本的核心逻辑是循环遍历每个位置，对每个字符（通常ASCII范围32-126）进行二分查找，根据HTTP响应内容的不同（可以通过比较响应体长度、或查找特定关键词如“商品不存在”）来判断真假。

4.2 时间盲注：最后的判断手段

如果开发者做得更绝，无论SQL查询条件真假，页面返回的内容都一模一样，没有任何可见差异，那么布尔盲注也将失效。此时，时间盲注成为了唯一的选择。

攻击思路： 我们无法从页面内容判断，但我们可以让数据库“睡一会儿”。通过构造一个条件，当条件为真时，执行一个睡眠函数，从而延迟页面响应时间；条件为假时，则立即返回。通过测量响应时间的长短，来判断我们的猜测是否正确。

在MySQL中，常用的延时函数是SLEEP(seconds)。但更隐蔽的方式是使用BENCHMARK(count, expr)，它通过重复计算一个表达式来消耗时间。 构造Payload：id=1 AND IF(ascii(substr(database(),1,1))=112, SLEEP(5), 0)这个语句的意思是：如果数据库名第一个字符的ASCII码等于112（‘p’），那么让数据库睡眠5秒，否则立即返回。攻击者发送请求后，用秒表（或脚本）计算响应时间。如果明显等待了约5秒，说明猜测正确；如果瞬间返回，说明猜测错误。

注意事项： 时间盲注非常依赖网络环境的稳定性，轻微的抖动可能导致误判。因此，在实际测试中，需要设置一个合理的延时阈值（比如，正常响应时间200ms，睡眠2秒，那么超过1.5秒就认为是真）。同时，时间盲注的速度极慢，猜一个字符可能需要数秒，整个拖库过程可能长达数小时甚至数天，对目标服务器也是一种明显的负载攻击，容易被发现。

5. 漏洞修复方案与深度防御

复现漏洞是为了更好地修复它。针对这个goods.php的SQL注入漏洞，修复不是简单地打补丁，而是要建立一套防御体系。

5.1 立即修复：参数化查询

这是根治SQL注入的最有效手段，没有之一。参数化查询（也称为预处理语句）的原理是将SQL语句的结构（模板）与数据（参数）分开发送给数据库。数据库先编译SQL结构，知道这是一个“查询id等于某个值的商品”的指令，然后再将用户输入的id值作为纯粹的数据绑定进去。这样，即使用户输入1 OR 1=1，它也会被当作一个完整的字符串值去匹配id字段，而不会被解释为SQL指令。

使用MySQLi扩展的修复代码如下：

<?php $conn = new mysqli(“localhost”, “root”, “password”, “shop”); $stmt = $conn->prepare(“SELECT * FROM goods WHERE id = ?”); // 问号是占位符 $stmt->bind_param(“i”, $_GET[‘id’]); // “i” 表示参数是整数类型 $stmt->execute(); $result = $stmt->get_result(); $row = $result->fetch_assoc(); // … 显示数据 … ?>

使用PDO扩展同样简单：

<?php $pdo = new PDO(“mysql:host=localhost;dbname=shop”, “root”, “password”); $stmt = $pdo->prepare(“SELECT * FROM goods WHERE id = :id”); $stmt->execute([‘:id’ => $_GET[‘id’]]); $row = $stmt->fetch(PDO::FETCH_ASSOC); ?>

为什么参数化查询是黄金标准？因为它从根源上分离了指令和数据，无论用户输入什么，都无法改变SQL语句的原始意图。这比任何过滤函数都更可靠。

5.2 辅助防御与最佳实践

虽然参数化查询是核心，但结合其他防御措施能构建更坚固的防线。

1. 输入验证与过滤： 在参数化查询之前，增加一层验证。对于id这种明确是数字的参数，可以使用intval()或filter_var()函数进行强制类型转换。$id = intval($_GET[‘id’]);这确保了即使攻击者传入恶意字符串，也会被转换为整数（非数字部分会被丢弃），为参数化查询又加了一把锁。但请注意，这不能替代参数化查询，因为其他类型的参数（如搜索关键词）无法简单转换。

2. 最小权限原则： 连接数据库的账户不应拥有root或db owner权限。应该为Web应用创建一个专属用户，只授予其对必要表（如goods,orders）的SELECT、INSERT、UPDATE权限，而绝对不要授予DROP、CREATE TABLE、FILE等高危权限。这样即使发生注入，危害也被限制在特定范围内。

3. 错误信息处理： 在生产环境中，务必关闭PHP的错误回显（display_errors = Off），并将错误日志记录到文件（log_errors = On）。避免将详细的数据库错误信息直接暴露给用户，这相当于给攻击者画了一张“地图”。

4. Web应用防火墙： 在应用层部署WAF（如ModSecurity），可以识别和拦截常见的SQL注入攻击模式，为应用提供一道额外的屏障。但它只是一种缓解措施，不能替代安全的代码。

5. 定期安全审计与代码扫描： 将安全作为开发流程的一部分。使用静态代码分析工具（SAST）对代码库进行扫描，自动发现潜在的SQL注入等漏洞。同时，定期进行渗透测试，模拟攻击者的行为来检验系统的安全性。

6. 常见问题与排查技巧实录

在复现和修复SQL注入漏洞的过程中，我遇到过不少坑。这里记录一些典型问题和解决思路，希望能帮你少走弯路。

问题1：明明使用了prepare和execute，但注入似乎仍然存在？

• 排查： 检查是否错误地使用了字符串拼接来构造SQL语句。例如：$stmt = $conn->prepare(“SELECT * FROM ” . $tableName . “ WHERE id = ?”);这里的表名$tableName如果是用户可控的，依然存在注入风险。预处理语句的占位符?只能用于数据值（WHERE条件、INSERT的值等），不能用于表名、列名等SQL标识符。
• 解决： 对于表名、列名等，必须使用白名单机制进行校验。例如，预先定义允许的表名数组，然后检查用户输入是否在该数组中。

问题2：在盲注时，如何准确判断页面“真”与“假”的差异？

• 技巧： 不要依赖肉眼。写一个简单的脚本，分别请求一个确定为真的Payload（如id=1 AND 1=1）和一个确定为假的Payload（如id=1 AND 1=2），抓取它们的HTTP响应。比较响应体的长度（len(r.content)）、哈希值，或者搜索页面中某个唯一且稳定的字符串（如商品名称）是否存在。将这个差异判断逻辑固化到你的自动化盲注脚本中。

问题3：时间盲注测试时，响应时间不稳定，导致误判率高。

• 技巧： 增加睡眠时间（如从2秒增加到5秒），以对抗网络抖动。同时，采用多次请求取平均值的策略。例如，对同一个猜测条件，连续发送3次请求，计算平均响应时间，再与基线时间比较。此外，可以尝试使用BENCHMARK(10000000, MD5(‘test’))代替SLEEP()，在某些环境下可能更稳定。

问题4：修复漏洞后，如何验证修复是否彻底？

• 方法： 不要只测试原来的Payload。使用全面的测试用例，包括：
  • 数字型：1 OR 1=1,1 AND SLEEP(5)
  • 字符型（如果其他参数是字符型）：’ OR ‘1’=’1,’ UNION SELECT …
  • 尝试编码绕过：%20（空格）,/**/（注释）,%a0（换行）
  • 使用自动化工具（如sqlmap）的--level和--risk参数提高测试强度，但务必在授权和隔离环境进行。 观察所有测试是否都返回了预期的、安全的结果（如只返回一条数据，或返回错误但不暴露信息）。

问题5：开发人员说“我们用了框架，所以没有注入风险”，这种说法对吗？

• 观点： 这种想法是危险的。主流框架（如Laravel的Eloquent、ThinkPHP的模型）通常提供了良好的ORM或查询构造器，它们内部使用了参数化查询，正确使用时能有效防止注入。但是，如果开发者不当使用，比如在框架中直接写原生SQL并拼接用户输入（例如DB::select(“SELECT * FROM users WHERE name = ‘“ . $name . “‘“)），注入风险依然存在。安全最终取决于开发者的意识和实践，而非工具本身。