SQL注入攻击原理、类型与防御实践-代码聚汇网

SQL注入攻击原理、类型与防御实践

丁茂华·2026-08-28·阅读 22 GEO检测（免费）

SQL注入Web安全参数化查询

|难度：普通|阅读约 13 分钟

1. 什么是SQL注入攻击

SQL注入（SQL Injection）是Web应用中最常见也最危险的漏洞之一。简单来说，就是攻击者通过在Web表单提交或URL参数中输入恶意的SQL代码，欺骗服务器执行非预期的SQL命令。

我第一次遇到SQL注入是在2015年维护一个电商网站时。当时发现后台日志中出现大量奇怪的SQL查询语句，比如：

sql复制SELECT * FROM users WHERE username = 'admin'--' AND password = 'xxx'

这个简单的--注释符就让整个密码验证逻辑失效了。攻击者只需知道管理员用户名，就能以admin身份登录系统。

1.1 SQL注入的危害等级

根据OWASP Top 10的长期排名，SQL注入一直位列Web安全威胁前三名。它能造成的危害包括：

数据泄露：获取数据库中的敏感信息
数据篡改：修改或删除重要数据
权限提升：获取管理员权限
服务器控制：通过数据库执行系统命令

最著名的案例是2009年Heartland支付系统被黑，导致1.3亿张信用卡信息泄露，攻击手段就是通过SQL注入。

1.2 SQL注入的工作原理

假设有一个简单的登录验证SQL：

sql复制SELECT * FROM users WHERE username = '$username' AND password = '$password'

如果用户输入：

用户名：admin'--
密码：任意值

实际执行的SQL变为：

sql复制SELECT * FROM users WHERE username = 'admin'--' AND password = 'xxx'

--后面的内容被注释掉，系统只检查用户名是否为admin，完全绕过了密码验证。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. SQL注入的常见类型

2.1 基于错误的注入

攻击者故意输入非法参数使数据库报错，从错误信息中获取数据库结构。例如：

sql复制SELECT * FROM products WHERE id = 1'

故意多一个单引号导致语法错误，有些系统会直接返回详细的错误信息。

重要提示：生产环境一定要关闭数据库错误回显，使用自定义错误页面。

2.2 基于布尔的盲注

当系统不显示错误信息时，攻击者通过真/假条件判断来获取数据。例如：

sql复制SELECT * FROM users WHERE username = 'admin' AND 1=1--'

如果页面正常返回，说明1=1条件成立，继续尝试其他判断条件。

2.3 基于时间的盲注

使用数据库的延时函数判断条件是否成立。例如MySQL中：

sql复制SELECT * FROM users WHERE username = 'admin' AND IF(1=1,SLEEP(5),0)--'

如果页面响应延迟5秒，说明条件成立。

2.4 联合查询注入

通过UNION合并恶意查询到原查询中。例如：

sql复制SELECT name, price FROM products WHERE id = 1 UNION SELECT username, password FROM users--'

这会将用户表数据一并返回。

3. 手工测试SQL注入漏洞

3.1 基础测试步骤

寻找注入点：所有用户输入的地方都可能存在风险
- URL参数
- 表单输入
- HTTP头（Cookie/User-Agent等）
- 文件上传名称等
测试特殊字符
- 单引号'：观察是否报错
- 注释符--或#
- 逻辑运算符AND/OR
判断数据库类型
- MySQL：version()、@@version
- MSSQL：@@version
- Oracle：SELECT banner FROM v$version

3.2 实用测试Payload

sql复制' OR 1=1--
" OR 1=1--
' OR 'a'='a
') OR ('a'='a
' UNION SELECT null,version()--
' AND SLEEP(5)--

4. 自动化SQL注入工具

4.1 sqlmap使用基础

sqlmap是最强大的开源SQL注入工具，基本用法：

bash复制sqlmap -u "http://example.com/page?id=1" --risk=3 --level=5

常用参数：

--dbs：枚举数据库
--tables：枚举表
--columns：枚举列
--dump：导出数据
--os-shell：获取系统shell

4.2 使用技巧

对POST请求测试：

bash复制sqlmap -u "http://example.com/login" --data="username=admin&password=123"

使用代理观察请求：

bash复制sqlmap -u "http://example.com/page?id=1" --proxy="http://127.0.0.1:8080"

绕过WAF：

bash复制sqlmap -u "http://example.com/page?id=1" --tamper=space2comment

5. 防御SQL注入的最佳实践

5.1 参数化查询（预编译语句）

这是最有效的防御手段。以PHP为例：

php复制// 不安全的方式
$query = "SELECT * FROM users WHERE username = '$username'";

// 安全的方式（使用PDO）
$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");
$stmt->execute([$username]);

Java中使用PreparedStatement：

java复制String sql = "SELECT * FROM users WHERE username = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, username);

5.2 其他防御措施

最小权限原则：数据库用户只赋予必要权限
输入验证：白名单验证输入格式
Web应用防火墙(WAF)：过滤恶意请求
错误处理：禁用详细错误信息
定期扫描：使用工具检查漏洞

5.3 代码审查要点

在代码审查时要特别注意：

字符串拼接的SQL查询
动态表名/列名的构建
ORM框架中的原生SQL执行
存储过程中的动态SQL

6. 真实案例分析

6.1 案例一：登录绕过

某系统登录SQL：

sql复制SELECT * FROM users WHERE username = '$user' AND password = '$pass'

攻击Payload：

code复制用户名：admin'--
密码：任意

最终执行：

sql复制SELECT * FROM users WHERE username = 'admin'--' AND password = 'xxx'

修复方案：改用参数化查询，并增加二次验证。

6.2 案例二：订单查询注入

某电商订单查询：

sql复制SELECT * FROM orders WHERE user_id = $user_id AND order_id = $order_id

攻击者构造：

code复制user_id=1&order_id=1 UNION SELECT 1,username,password,4 FROM users--

修复方案：验证order_id必须为数字，使用预编译语句。

7. 高级话题：ORM框架与SQL注入

7.1 ORM不是银弹

虽然ORM框架通常能防止SQL注入，但不正确使用仍然存在风险：

python复制# Django不安全示例
User.objects.raw("SELECT * FROM users WHERE username = '%s'" % username)

# 安全的方式
User.objects.raw("SELECT * FROM users WHERE username = %s", [username])

7.2 MyBatis中的$和#区别

xml复制<!-- 不安全：使用${}直接拼接 -->
SELECT * FROM users WHERE username = '${username}'

<!-- 安全：使用#{}参数化 -->
SELECT * FROM users WHERE username = #{username}

8. 企业级防护方案

8.1 分层防御体系

前端：输入验证、长度限制
应用层：参数化查询、ORM安全使用
数据库层：最小权限、存储过程
网络层：WAF、入侵检测

8.2 安全开发流程

安全培训：所有开发人员
代码规范：禁止字符串拼接SQL
自动化扫描：SAST工具集成到CI/CD
渗透测试：定期安全评估

我在实际项目中发现，最有效的防御是开发团队的安全意识提升+自动化工具检查的组合。单纯依赖工具或人工审查都容易有遗漏。