文章总结： 本文系统解析SQL注入的原理、分类、检测思路与防御方案。核心观点是SQL注入源于用户输入与SQL代码的字符串拼接，导致输入被解析为语法。文章详细介绍了联合查询、报错、布尔盲注等六大注入类型，并提供了合规测试流程。防御重点在于使用参数化查询，并建立纵深防御体系，包括WAF、最小权限原则等。文章强调安全测试需获得授权，适合开发者和安全学习者建立系统认知。 综合评分： 85 文章分类： WEB安全,渗透测试,安全开发,安全建设,技术标准

---

SQL注入攻击全解析-CSDN博客

原创

钟智强 钟智强

哪吒网络安全

2026年7月4日 18:52 马来西亚

在小说阅读器读本章

去阅读

SQL 注入攻击全解析

原理 · 分类 · 检测思路 · 防御体系【图解全指南】

标签：Web 安全 · SQL 注入 · 渗透测试 · 安全开发 · OWASP

面向对象：Web 开发工程师 / 安全学习者 / 渗透测试入门读者

| | | — | | 写在前面 本文聚焦 SQL 注入的原理、分类、检测思路与防御方案，帮助开发者和安全学习者建立系统认知。 文中出现的示例 payload 均为业界广泛公开的基础用法（同类内容可在 OWASP、PortSwigger Web Security Academy 等资料中查到），不包含针对具体系统的攻击教程，也不涉及权限提升、痕迹清除等攻击性内容。 任何安全测试都请仅在获得书面授权的环境中进行——未经授权测试他人系统属于违法行为。 |

目录

前言

一、SQL 注入到底是什么

二、SQL 注入的分类

三、常见测试思路（合规场景下的验证方法）

四、基础 Payload 示例

五、自动化检测工具

六、关于 WAF 绕过的几点认识

七、防御方案：怎么把 SQL 注入挡在外面

八、漏洞分级与合规映射

九、真实世界案例

十、学习资源推荐

十一、总结

前言

SQL 注入（SQL Injection，简称 SQLi）这个话题已经被讨论了二十多年，但它从未真正“过时”。在 OWASP Top 10 里，注入类漏洞常年排在前列；CWE 漏洞分类体系给它单独分配了编号 CWE-89；即便到今天，公开披露的数据泄露事件里，仍能不时看到“某个未做参数化处理的 SQL 语句”这样的根因描述。

这篇文章想把 SQL 注入这件事讲得系统一些：它为什么会发生、常见的类型都有哪些、安全测试人员大致怎么验证一个疑似漏洞、以及——这是最重要的部分——作为开发者，应该怎样从代码层面把这类问题挡在门外。全文配了 5 张图，尽量把容易讲绕的流程和对比用图表达出来，帮助建立一个相对完整的知识框架。

需要说明一点：本文的目标读者是想理解这个漏洞、写出更安全代码的开发者，以及刚入门 Web 安全的学习者，所以内容会更偏向“原理 + 防御”，一些涉及服务器提权、痕迹隐藏之类的攻击性技巧不会展开——网上能找到，但那不是这篇文章想传递的东西。

一、SQL 注入到底是什么

先看一个最经典的场景。假设一个登录接口，后端代码大致是这样写的（示例用 PHP，但道理对任何语言都一样）：

| | | — | | $sql = “SELECT * FROM users WHERE username='” . $_GET[‘u’] . “‘”; $result = mysqli_query($conn, $sql); |

正常情况下，用户在参数里传入 alice，拼接出来的语句就是查 alice 这一条记录，一切正常。但如果传入的不是一个正常的用户名，而是一段 SQL 语法片段，比如 ‘ OR ‘1’=’1，拼接后的语句就变成了：

| | | — | | SELECT * FROM users WHERE username=” OR ‘1’=’1′ |

WHERE 后面的条件永远为真，于是这条语句会返回表里的所有记录——攻击者可能借此绕过登录校验，或是把不该被看到的数据一次性拿到。

图 1：正常输入与恶意输入在拼接后走向了完全不同的执行逻辑

这就是 SQL 注入的本质：只要应用把“用户输入”和“SQL 代码”用字符串拼接的方式混在一起，输入的内容就有可能被数据库当成语法的一部分来解析，而不是被当作单纯的数据。程序原本期望用户老老实实填一个用户名，但数据库并不知道“期望”是什么，它只负责解析收到的语法——单引号一旦提前把原字符串闭合，后面跟着的任何内容都会被当作正常的 SQL 关键字、运算符和条件来执行。

只要这个“代码 / 数据边界”没有被严格保护，注入就有可能发生——不管载体是登录框、搜索框、URL 参数，还是 HTTP 请求头、Cookie、JSON 请求体、GraphQL 变量，任何最终会被拼进 SQL 语句的输入，理论上都是潜在的风险点。这也是为什么 SQL 注入即使在“Web 1.0”年代就被发现，放到今天的 REST API、GraphQL 接口里依然适用同一套原理。

| | | — | | 一句话理解根本原因 字符串拼接构造 SQL ≠ 一定有漏洞，但只要拼接的内容来自用户可控输入、且没有做任何隔离处理，风险就实际存在。 反过来，用了参数化查询 / 预编译语句，就从根本上切断了“输入变成代码”的可能性——这也是第七部分“防御方案”里最核心的一条。 |

二、SQL 注入的分类

从“怎么把数据拿出来”这个角度出发，可以把 SQL 注入大致分成六大类。理解分类的意义不在于死记名词，而在于遇到一个疑似注入点时，能快速判断“这次能用哪种方式”——页面有没有回显、会不会报错、能不能感知到时间差，决定了可用的手段。

图 2：SQL 注入六大类型全景图

1. 联合查询注入（UNION-based）

如果页面会把查询结果直接显示出来，攻击者可以用 UNION SELECT 拼接一条新的查询，把其他表的数据接到正常的回显位置上。这是最直接、效率最高的一种方式，前提是能确定原查询的字段数量，并且字段类型要能对应上。

2. 报错注入（Error-based）

有些应用会把数据库的报错信息直接展示在页面上（调试模式没关，或异常处理没兜底）。攻击者可以故意构造会触发报错的语句，让想要的数据“混”在错误提示信息里被带出来，常见于 MySQL 的 xpath 相关函数报错。

3. 布尔盲注（Boolean-based Blind）

页面不会直接把数据“打印”出来，也不报错，但对“条件为真”和“条件为假”这两种情况的响应存在细微差别（页面内容不同、返回的状态码不同等）。攻击者靠反复对比这种差异，一位一位地把数据猜出来。

4. 时间盲注（Time-based Blind）

比布尔盲注更极端的情况：页面对真假条件的响应连“差异”都看不出来，唯一的线索是响应耗时。攻击者在语句里加入 SLEEP()、WAITFOR DELAY 之类的延时函数，让“条件为真”时数据库多等几秒，通过掐表来判断真假。

5. 堆叠注入（Stacked Queries）

部分数据库和访问方式支持用分号 ; 分隔，在一次请求里执行多条语句。如果具备这个条件，追加的语句理论上可以是任意语句，但由于后续语句的结果通常不会直接回显，往往还要配合盲注手段才能确认执行效果。

6. 二次注入（Second-order Injection）

容易被忽视的一种。恶意数据第一次提交时可能被“好好地”转义或校验过、安全地存了进去，但如果后续某个功能把这条数据再次取出来、不加处理地拼进另一条 SQL 语句里，攻击照样会触发——问题不在输入的那一刻，而在后面被“二次使用”的地方。

7. 带外注入（Out-of-band, OOB）

如果页面既没有回显、也无法通过时间差判断（比如语句是异步执行的），部分场景下可以尝试让数据库主动通过 DNS、HTTP 等“额外通道”把数据传给攻击者控制的服务器。这种方式对网络出口环境要求较高，是前两种手段都失效时的备选方案。

布尔盲注 vs 时间盲注：两种“猜”法的直观对比

盲注是实战中最常遇到、也最容易讲混的一类，这里单独用一张图把两种手法的判断逻辑摆在一起对比：

图 3：布尔盲注靠“内容差异”判断，时间盲注靠“耗时差异”判断

各数据库的语法差异一览

同样的注入思路，落到不同数据库上，语法细节会不一样。下面整理了几个高频用到的差异点，实战中可以据此快速判断目标数据库类型：

| 特性 | MySQL | SQL Server | PostgreSQL | Oracle | SQLite | | — | — | — | — | — | — | | 单行注释 | — 或 # | — | — | — | — | | 字符串拼接 | CONCAT(a,b) | a + b | a || b | a || b | a || b | | 版本查询 | version() | @@version | version() | v$version 视图 | sqlite_version() | | 延时函数 | SLEEP(n) | WAITFOR DELAY | pg_sleep(n) | 借助 PL/SQL | 无原生延时函数 | | 当前用户 | current_user() | current_user | current_user | user | 无内建等价函数 | | 元数据视图 | information_schema | information_schema | information_schema | 数据字典视图 | sqlite_master |

三、常见测试思路（合规场景下的验证方法）

了解了分类之后，安全测试人员大致会按什么思路去验证一个“疑似注入点”？下面是一个比较通用的流程，核心思想是“先粗判、再细化”：先看有没有明显信号，再决定往报错 / 联合查询方向深入，还是转向盲注。

图 4：SQL 注入检测与验证的通用思路

流程图之外，还有几个值得补充的要点：

•先排除误报：响应差异也可能是网络抖动、缓存、限流之类的因素造成的，最好多测几次、控制好变量再下结论。

•字段数的判断（ORDER BY 或 UNION SELECT NULL 递增测试）看似简单，却是后续联合查询能否成功的关键一步，值得多花时间确认准确。

•枚举数据库结构时，不同数据库的元数据视图不同（见上一部分对照表），选错了视图会一直无结果，容易误判为“此路不通”。

•验证到“能读出一两条非敏感数据”即可作为漏洞证据，测试的目的是证明风险存在并推动修复，而不是尽可能多地拉取数据。

| | | — | | 关于授权 在任何非自己拥有的系统上执行以上测试，都需要事先获得书面授权（如渗透测试合同、漏洞赏金计划范围说明等）。 未经授权访问或探测他人系统，即便“只是想看看有没有漏洞”，在多数法域下也可能构成违法行为。 |

四、基础 Payload 示例

下面这些是帮助理解各类注入“长什么样”的基础示例，在 OWASP、PortSwigger 等公开资料中都能找到同类写法，目的是配合前面的分类说明，不是“拿来即用”的工具箱。真实环境中的可用性会因为具体的 SQL 方言、括号使用方式、过滤规则等因素而有很大差异。

| 类型 | 示例 Payload | 说明 | | — | — | — | | 判断注入点 | ‘ AND 1=1 — / ‘ AND 1=2 — | 对比两次响应是否不同，是最基础的探测方法 | | 注释截断 | admin’ — | 用注释符截断原语句后面剩余的部分 | | 布尔恒真 | ‘ OR ‘1’=’1 | 让 WHERE 条件恒为真，常用于讲解原理 | | 联合查询探测 | ‘ UNION SELECT NULL,NULL,NULL — | 先用 NULL 占位探测字段数，再逐个替换为具体列 | | MySQL 报错注入 | ‘ AND extractvalue(1,concat(0x7e,version())) — | 利用 XML 解析函数报错，把 version() 结果带出来 | | MySQL 时间盲注 | ‘ AND IF(1=1,SLEEP(3),0) — | 条件为真时人为延时 3 秒，通过耗时判断真假 | | SQL Server 时间盲注 | ‘; WAITFOR DELAY ‘0:0:3’ — | SQL Server 下等价的延时测试写法 | | PostgreSQL 时间盲注 | ‘; SELECT pg_sleep(3) — | PostgreSQL 的延时函数 |

五、自动化检测工具

手工测试之外，业界有一些成熟的工具可以大幅提升效率，这里只做概念性介绍，不展开具体操作步骤：

sqlmap：最常用的开源 SQL 注入检测与验证工具，能自动判断注入点类型、识别数据库种类、辅助枚举数据库结构，是安全从业者在授权测试中的常备工具。

Burp Suite：Web 安全测试平台，配合 Repeater、Intruder 等模块可以手动构造和批量测试注入 payload，也是 Web 安全学习中最主流的抓包改包工具。

DAST / AppSec 扫描平台：企业级动态应用安全测试平台通常内置了 SQL 注入等常见漏洞类型的自动化扫描能力，可以覆盖手工测试难以穷尽的参数组合。

无论使用哪种工具，都只应该在自己拥有的资产或已获得书面授权的范围内运行——这些工具的检测能力越强，未经授权使用带来的法律风险也越高。

六、关于 WAF 绕过的几点认识

很多团队上线 Web 应用防火墙（WAF）之后会有一种“万事大吉”的错觉，但 WAF 规则本质上是基于特征匹配的，而特征匹配天然存在被绕过的可能。了解这一点不是为了教怎么绕过，而是为了理解“为什么不能只依赖 WAF”——这也是第七部分“纵深防御”的核心论据。

•大小写混淆、内联注释拆分关键字：把敏感关键字拆开或变形，可能绕过基于简单字符串匹配的规则。

•编码变形：URL 编码、Unicode 编码等方式可能让请求在到达应用层被解码后才“还原”出真正的语义。

•等价写法替换：同一个逻辑往往有多种 SQL 写法可以表达，规则很难穷尽所有等价形式。

正因为 WAF 存在被绕过的可能，业界的共识是把它当作纵深防御中的“第一层过滤网”，而不是唯一防线——真正兜底的，是代码层面的参数化查询和数据库层面的最小权限设计，这两点我们在下一部分详细展开。

七、防御方案：怎么把 SQL 注入挡在外面

如果只能记住这篇文章的一句话，那应该是：SQL 注入是一个“有明确、成熟解法”的老问题，只要把参数化查询落实到位，绝大多数场景下的风险就能被消除。但工程实践中，“知道要用参数化查询”和“整个系统所有查询都做到了”之间往往有很大差距，所以还是要建立多层防御，让任何单一环节的疏漏都不会直接导致数据泄露。

图 5：SQL 注入的纵深防御体系——从外层过滤到核心的参数化查询，再到权限与审计兜底

7.1 参数化查询 / 预编译语句（最核心的一条）

参数化查询的核心思想是：把 SQL 语句的“结构”和“数据”彻底分开传给数据库。语句结构在编译阶段就已经固定，用户输入无论包含什么字符，都只会被当作参数值本身，不再有机会被解析成 SQL 语法的一部分。下面是几种主流语言的写法：

Java（JDBC PreparedStatement）

| | | — | | String sql = “SELECT * FROM users WHERE username = ? AND password = ?”; PreparedStatement stmt = connection.prepareStatement(sql); stmt.setString(1, username); stmt.setString(2, passwordHash); ResultSet rs = stmt.executeQuery(); |

Python（DB-API 占位符）

| | | — | | cursor.execute(     “SELECT * FROM users WHERE username = %s AND password = %s”,     (username, password_hash) ) |

PHP（PDO）

| | | — | | $stmt = $pdo->prepare(‘SELECT * FROM users WHERE username = :username’); $stmt->execute([‘username’ => $username]); $user = $stmt->fetch(); |

Node.js（mysql2 占位符）

| | | — | | const [rows] = await connection.execute(   ‘SELECT * FROM users WHERE username = ? AND password = ?’,   [username, passwordHash] ); |

| | | — | | 常见误区 字符串拼接 + 手动转义（如 addslashes、mysql_real_escape_string）不是参数化查询，只是“风险更低的拼接”，仍有被特定编码或场景绕过的可能，不应作为长期方案。 凡是能用占位符表达的场景，就不要再用字符串拼接构造 SQL——包括看起来“很安全”的整数型参数，也建议统一走参数化，避免疏漏。 |

7.2 合理使用 ORM，但别忽视“逃生舱口”

Hibernate、SQLAlchemy、Sequelize、MyBatis 等主流 ORM / 数据访问框架在标准用法下都会自动使用参数化查询，这也是推荐使用成熟框架而不是手写 SQL 拼接的原因之一。但几乎所有框架都留了“逃生舱口”——原生 SQL 拼接接口（比如某些 ORM 里的 raw() 或字符串形式的动态排序/字段名），这些地方如果直接拼入用户输入，同样会引入注入风险。排查代码时，这类“看似用了 ORM，其实是手写拼接”的调用点是重点排查对象。

7.3 输入验证与白名单过滤

参数化查询解决不了所有场景，比如排序字段名、表名这类无法用占位符表达的“结构性”输入，就需要用白名单校验：提前定义好合法值的集合（例如允许排序的字段只有 created_at、price 这几个），用户输入只要不在白名单里就直接拒绝，而不是尝试转义后放行。类型、长度、格式的基础校验也应该在这一层完成。

7.4 最小权限原则

应用连接数据库使用的账户，应该只被授予业务实际需要的最小权限——只读业务就不要给写权限，普通业务账户不需要能访问系统表、创建/删除表、执行管理类存储过程的权限。这样即便某处查询真的被注入，攻击者能做的事情也会被数据库权限严格限制在一个小范围内，很大程度上决定了“一个漏洞”和“一场重大事故”之间的差距。

7.5 错误处理与信息脱敏

数据库返回的原始报错信息（包含 SQL 语句片段、表结构线索、数据库版本等）不应该直接展示给用户，生产环境要统一捕获异常并返回脱敏后的通用错误提示，详细堆栈只写入服务端日志供排查使用。这一步能直接堵住“报错注入”这一整类攻击路径。

7.6 WAF：纵深防御的一层，而非唯一防线

结合第六部分的讨论，WAF 适合作为快速拦截已知攻击特征的第一层过滤，尤其对批量扫描、自动化攻击工具有较好的拦截效果，但不应该是唯一依赖的防线——它需要和参数化查询、最小权限等代码 / 数据库层面的措施配合使用。

7.7 安全审计与自动化扫描（SAST / DAST）

在 CI/CD 流程中集成静态代码扫描（SAST）可以在代码提交阶段就发现字符串拼接构造 SQL 的高风险写法；动态应用安全测试（DAST）则可以在运行时黑盒验证接口是否存在可被利用的注入点。两者结合，加上定期的人工代码审查和授权渗透测试，能把“写完就不再检查”的风险窗口尽量缩短。

7.8 日志监控与异常检测

对数据库慢查询、异常大量的报错请求、包含可疑 SQL 关键字的请求参数进行监控告警，能在攻击尝试阶段就被发现，而不是等到数据已经泄露才知晓。这一层更多起到“及时发现”的作用，是对前面几层防御的补充，而不是替代。

7.9 数据库层面的加固

关闭业务不需要的数据库特性（例如不必要的多语句执行能力）、及时安装数据库安全补丁、对数据库网络访问做严格的网络分段和白名单限制，都能在“万一被注入”的情况下进一步限制攻击者能触达的范围。

八、漏洞分级与合规映射

SQL 注入在各类安全标准里都有明确的位置：在 CWE 通用弱点枚举体系中编号为 CWE-89；在 OWASP Top 10（2021 版）中归属于 A03 — Injection（注入）大类；PCI DSS 支付卡行业数据安全标准也明确要求应用必须防范注入类攻击。这些标准的存在本身就说明，SQL 注入不是一个“小众”或“理论上的”问题，而是长期被主流安全体系重点关注的高优先级风险。

九、真实世界案例

两个被反复引用的经典案例，能帮助理解 SQL 注入在真实世界里造成的影响：

Heartland Payment Systems（2008）

美国支付处理商 Heartland Payment Systems 在 2007 年底遭到攻击，攻击者通过一个已经上线 8 年的旧版网页登录表单中的 SQL 注入漏洞进入其公司网络，随后耗费数月时间绕过多套防病毒系统、逐步渗透到支付处理网络，最终植入嗅探程序窃取交易数据。这次事件最终导致超过一亿张银行卡信息暴露，成为当时已披露的最大规模支付卡数据泄露事件之一，Heartland 也为此付出了远超百万美元的赔偿与整改成本。这个案例常被用来说明：一个长期没人关注的“旧页面”，也可能是整个网络里最薄弱的入口。

TalkTalk（2015）

英国电信运营商 TalkTalk 在 2015 年 10 月遭到攻击，攻击者使用 sqlmap 工具对其从收购的 Tiscali 继承下来的遗留网页进行探测，发现其中存在 SQL 注入漏洞，且底层 MySQL 数据库使用了一个三年前就已公开修复方案的旧版本。攻击最终导致约 15.7 万客户的个人信息被访问，其中约 1.56 万人的银行账户信息被窃取。英国信息专员办公室（ICO）随后对 TalkTalk 处以 40 万英镑罚款——这在当时是 ICO 开出的最高罚单，理由之一就是“SQL 注入是一种广为人知、早已有成熟防御方案的攻击方式”。这个案例常被拿来强调：“技术上早就有解法”和“真的把它落实到每一处遗留系统”完全是两件事。

两个案例的共同点值得注意：漏洞本身都出现在容易被忽视的“遗留页面”上，而不是核心新功能里。这也提示了一个现实的防御重点——遗留系统和历史代码的排查，往往比新代码的安全评审更容易被忘记。

十、学习资源推荐

OWASP SQL Injection：OWASP 官方对 SQL 注入的权威说明，涵盖原理、检测与防御建议，是这个主题最应该优先阅读的资料。

OWASP Testing Guide：OWASP 测试指南中关于注入类漏洞的测试方法论章节，偏重系统化的测试流程。

PortSwigger Web Security Academy：提供免费、可实操的在线练习环境，SQL 注入相关的一系列免费实验室适合边学边练。

OWASP Top 10：了解注入类漏洞在整个 Web 安全风险版图中的位置。

十一、总结

回顾一下这篇文章想传递的几个核心信息：SQL 注入的根源是用户输入和 SQL 代码的边界没有被严格隔离；它可以按数据获取方式分成联合查询、报错、布尔盲注、时间盲注、堆叠、二次注入、带外七大类，每一类适用的场景和判断方法都不同；安全测试有一套相对固定的验证思路，但任何测试都必须建立在授权基础之上；而防御的核心只有一句话——参数化查询解决根本问题，最小权限、输入验证、错误处理、WAF、审计监控这些措施构成纵深防御，让任何单点的疏漏都不至于演变成一次大规模的数据泄露。

SQL 注入已经是一个“有成熟解法”的老问题，但正如 TalkTalk 案例所展示的，“知道怎么防”和“真正把每一处代码都落实到位”之间，仍然存在着不小的距离——这也正是它至今仍出现在 OWASP Top 10 里的原因。希望这篇文章能帮你把这个经典漏洞的原理和防御思路理清楚，写代码时多一分警惕。

如果这篇文章对你有帮助，欢迎点赞、收藏，也欢迎在评论区交流你在实际项目中遇到过的注入相关问题～我们下篇文章再见！

哪吒网络安全 #SQL注入 #sql

---

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：哪吒网络安全 钟智强 钟智强《SQL注入攻击全解析-CSDN博客》