[分享]什么是SQL注入？

SQL 注入：数据库的"万能钥匙"

如果把 DDoS 比作堵门，CC 攻击比作骚扰电话，那 SQL 注入（SQL Injection） 就是直接拿钥匙开门进屋搬东西——而且这把钥匙，往往是你自己亲手递出去的。

它不是暴力破解，不是流量碾压，而是一段精心构造的恶意代码，伪装成正常输入混进你的数据库，然后执行攻击者想干的任何事：拖走用户数据、删光表、甚至拿到服务器的 shell 权限。

从"拼接字符串"说起：漏洞是怎么诞生的

大多数 SQL 注入漏洞的根源，只有一个：开发人员把用户的输入，直接拼进了 SQL 语句里。

来看一个最经典的例子。假设你在登录页面输入用户名和密码，后端代码执行了这样的操作：

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

如果代码是用字符串拼接的方式构造这条 SQL 的：

1	query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'"

当用户正常输入时，这没问题。但如果攻击者在密码框里输入的是：

1	' OR '1'='1

拼出来的 SQL 就变成了：

1	SELECT * FROM users WHERE username = 'admin' AND password = '' OR '1'='1'

'1'='1' 永远为真，整条语句的 WHERE 条件就变成了 “用户名是 admin，并且（密码为空或 1=1）” ，而 1=1 恒成立，所以整个 WHERE 子句永远为真。这条查询会返回 users 表中的所有行——攻击者不需要知道密码，就直接以 admin 身份登入了系统。

这还只是最简单的"万能密码"绕过，SQL 注入能做到的事情远不止于此。

一个更阴险的变种：同样是这个场景，攻击者如果输入 admin'--，拼出来的 SQL 就变成 SELECT * FROM users WHERE username = 'admin'--' AND password = ''。在 SQL 中，-- 是注释符，后面的 AND password = '' 会被完全忽略。这样攻击者同样不需要密码就能以 admin 登录。这种"注释掉剩余条件"的手法，比 OR '1'='1' 更隐蔽。

攻击的三层杀伤力

根据攻击目标的不同，SQL 注入可以造成三种级别的破坏。

第一层：数据泄露（读取）

攻击者利用 UNION 或报错信息，把数据库里的敏感数据一条条"掏"出来。

经典的 UNION 注入示例：
1
SELECT name, price FROM products WHERE id = 1 UNION SELECT username, password FROM users
如果 products 表的查询结果和 users 表的列数恰好匹配，攻击者就能在商品列表页面上看到所有用户的账号密码。

危害：用户隐私（身份证、手机号、地址）、企业商业机密、管理员账号密码，全部暴露。

第二层：数据篡改与删除（写入）

通过堆叠查询（Stacked Queries），攻击者可以在一条语句后追加另一条：

1	SELECT * FROM products WHERE id = 1; DROP TABLE users; --

如果数据库支持多语句执行，users 表就被直接删除了。更隐蔽的做法是修改数据：把商品价格改成 0.01 元下单，或者把自己的账户余额加几个零。

第三层：获取服务器控制权（RCE 的跳板）

在某些极端配置下（如 SQL Server 启用 xp_cmdshell 扩展），攻击者可以通过 SQL 注入直接执行操作系统命令：

1	EXEC xp_cmdshell 'whoami' -- 查看当前服务器运行身份

一旦拿到服务器权限，整台机器就彻底沦陷了。它可以被用来发起内网横向渗透、安装勒索病毒、或者作为肉鸡参与 DDoS 攻击——一个 SQL 注入漏洞，可能成为整条业务链失守的起点。

为什么 SQL 注入至今仍然存在？

SQL 注入漏洞早在 1998 年就被公开报道，近三十年过去了，它依然稳居 OWASP Top 10 榜单。原因很现实：

历史遗留代码：大量老项目用的还是拼接字符串的方式，重构成本高、风险大。
开发安全意识薄弱：赶工期时"先上线再说"，忽略了输入校验。
框架使用不当：有些开发人员用 ORM 框架却依然写原生 SQL 拼接，绕过了框架自带的安全机制。
数据库配置不当：应用账号拥有过高权限（如 DBA），一个注入点就能删库。

防御之道：从"堵漏洞"到"建城墙"

SQL 注入的防御思路早已成熟，核心就是一句话：永远不要信任用户的输入。

第一层：参数化查询（PreparedStatement）——最根本的防线

这是防御 SQL 注入最有效、最标准的方法。将 SQL 语句的结构和参数数据分开发送给数据库：

String sql = "SELECT * FROM users WHERE username = ? AND password = ?";
PreparedStatement ps = conn.prepareStatement(sql);
ps.setString(1, username);
ps.setString(2, password);

数据库先解析 SQL 的结构，把 ? 当作占位符，然后再把参数值填入。参数值只会被当作纯数据处理，其中的任何 SQL 关键字（OR '1'='1'）都不会被当作代码执行。

关键要点：参数化查询只能防止"数据值"位置的注入，但不能防止"表名/列名/ORDER BY 排序字段"等结构位置的注入。如果业务需要动态拼接这些结构元素，必须在代码层面用白名单校验。

第二层：输入验证与白名单

白名单校验：对于枚举类型的输入（如性别、状态码），只允许预设的值通过。
类型强制转换：对于数字类型的参数，使用 Integer.parseInt() 等强制转换，彻底排除非数字字符。
长度限制：过长的输入字符串往往是攻击信号，截断或拒绝。

重要原则：永远不要依赖黑名单（比如过滤 '、OR、SELECT 等关键字）。攻击者可以双写绕过（SELSELECCTECT）、大小写绕过（SeLeCt）、编码绕过（%27），黑名单永远堵不全。

第三层：最小权限原则（数据库账号）

应用连接数据库的账号，只应该拥有它完成业务所需的最小权限：

业务需求	该给的权限	不该给的权限
用户查询	SELECT	INSERT、UPDATE、DELETE
用户注册	INSERT	SELECT * FROM other_table
商品展示	SELECT	DROP、ALTER、CREATE

如果一个查询接口只需要读数据，就用只读账号。即使被注入了 DROP TABLE，权限不够也执行不了。这是纵深防御的最后一道底线。

第四层：错误信息隐藏

攻击者的很多信息来自数据库的报错消息。一条详细的错误日志可能暴露表名、列名甚至 SQL 结构。

生产环境关闭详细错误：不要在页面直接显示数据库错误，返回一个通用的"系统繁忙"或记录到后台日志。
使用通用错误页面：让攻击者无法从错误信息中推断出数据库结构和注入点是否成功。

第五层：Web 应用防火墙（WAF）

WAF 可以作为第一道闸门，在请求到达应用之前就进行过滤：

识别并拦截包含 SQL 关键字、特殊字符的异常请求。
对高频访问、集中攻击进行速率限制。

但要注意：WAF 是辅助手段，不是根本解决方案。WAF 可以被绕过（大小写、编码、注释符），真正的安全在代码层面。

第六层：定期安全审计

代码审查（Code Review）：定期检查是否存在字符串拼接 SQL 的"坏味道"。
自动化扫描工具：使用 sqlmap、AppScan 等工具主动探测漏洞点。
渗透测试：请安全团队以攻击者的视角寻找弱点和突破路径。

攻击者的视角：如何快速定位注入点

理解攻击者的方法，才能更好地防御。

攻击者在探测注入点时，最常见的"信号"就是在 URL 参数或表单输入框后面加一个 单引号 '：

1	https://example.com/product?id=1'

如果页面返回了数据库错误信息（如 You have an error in your SQL syntax），攻击者就知道这里存在注入点，并且能推断出数据库类型和 SQL 结构。这就是为什么错误信息隐藏如此重要。

接下来，攻击者会用各种"指纹"来探测注入类型和数据库版本：

-- 探测列数
?id=1 ORDER BY 3  -- 如果页面正常，说明查询返回了3列
?id=1 ORDER BY 4  -- 如果报错，说明只有3列

-- 探测数据库版本
?id=1 UNION SELECT @@version   -- MySQL
?id=1 UNION SELECT version()   -- PostgreSQL
?id=1 UNION SELECT banner FROM v$version  -- Oracle

不同数据库的返回格式、报错信息都不同，攻击者通过这些"指纹"就能快速锁定目标。