SQL 注入

原理与分类

典型场景：登录表单用户名字段输入 ' OR '1'='1，若代码直接拼接 SQL 字符串，查询就变成了永真条件，绕过密码验证。这是最朴素的「经典注入」。

按数据回显方式，注入分为三类：

联合查询注入（Union-based）：利用 UNION SELECT 把额外数据拼到正常回显中，要求页面输出查询结果。
布尔盲注（Boolean-based Blind）：无页面回显，靠页面真/假两种响应状态逐位猜出数据，通常需要数百到数千次请求。
时间盲注（Time-based Blind）：用 SLEEP() 或 WAITFOR DELAY 制造延迟，无需任何页面差异即可提取数据，对无回显且无错误信息的场景最有效。
带外注入（OOB）：借助 DNS/HTTP 请求把数据外带出去，对防火墙极严的环境仍有效。

2009 年，工具 sqlmap 开源，极大降低了实施 SQL 注入的门槛，也推动了各大框架加速默认启用参数化查询。[1]

预编译语句（Prepared Statements）是根本性防御：驱动层先发送 SQL 结构再发送数据，数据永远不会被解析为指令。Java 的 PreparedStatement、Python 的 psycopg2 占位符、PHP 的 PDO 均是正确姿势。

但要注意：动态拼接表名或列名无法参数化，必须用白名单校验。存储过程若内部仍做字符串拼接，同样有注入风险。ORM 框架的「原生查询」接口（如 Hibernate 的 createNativeQuery）被错误使用时也会出问题。

2011 年索尼 PlayStation Network 泄露 7700 万用户数据，调查报告明确指出根因是未做参数化处理的 SQL 查询——这次事件推动了全行业重新审视 SQL 注入的危害等级。