SQL注入攻击的本质，是应用程序在构造数据库查询语句时，没有严格区分“代码”与“数据”，导致用户提交的恶意字符串被数据库引擎当作SQL指令的一部分执行。假设一个登录接口直接把前端传来的用户名和密码拼接到查询中，攻击者就能通过特殊字符改变语句原意，从而绕过认证、读取敏感表甚至写入木马。理解这一原理，是写出安全接口的第一步。
SQL注入的基础原理与语句解析流程
数据库在执行SQL时，会先将整段文本交给解析器做词法、语法分析，再生成执行计划。正常场景下，程序员写的SQL模板里，用户输入只是被引号包裹的字面量。但当拼接发生时，用户输入中的单引号会提前闭合原字符串，后续内容便升级为SQL关键字或条件。例如原语句是 SELECT * FROM user WHERE name='$name' AND pwd='$pwd'，若 $name 值为 admin' --，单引号闭合了name的字符串，双减号在多数数据库中表示注释，于是密码校验被直接忽略。
从解析角度看，注入成功是因为程序把“数据域”错误地暴露给了“指令域”。MySQL、SQL Server等都会在协议层把完整SQL文本发给服务端，服务端无法自动判断哪部分来自可信代码、哪部分来自不可信输入。这就要求在编码阶段主动隔离两者。很多初学者误以为“过滤掉单引号”就安全，实际上宽字节、二次编码、不同数据库注释语法都会绕过简单过滤，必须依赖更底层的机制。
另一个常被忽略的点是错误回显。当注入引发语法错误或类型转换异常，若系统把原始报错返回给前端，攻击者能借机推断表名、列名。因此原理层面不仅要防执行越权，还要控制信息泄露面。下面用具体危险写法展示常见陷阱。
典型危险SQL示例与攻击演示
最经典的漏洞写法就是字符串拼接。下面这段PHP代码直接把 $_GET 参数放进查询，任何人都可在浏览器里构造 id=1 OR 1=1 让条件恒真，拖出全表数据。
<?php $id = $_GET['id']; $sql = "SELECT title, content FROM article WHERE id = $id"; $result = mysqli_query($conn, $sql); // 攻击者在地址栏输入 ?id=1 UNION SELECT username, password FROM admin // 原语句变为: SELECT title, content FROM article WHERE id = 1 UNION SELECT username, password FROM admin ?>
另一个高频场景是登录绕过。以下代码用双引号包裹变量，攻击者在密码框输入 ' OR '1'='1 即可让where条件永远成立。
import sqlite3
conn = sqlite3.connect("app.db")
user = input("用户名: ")
pwd = input("密码: ")
cur = conn.cursor()
sql = "SELECT * FROM user WHERE name = '%s' AND pass = '%s'" % (user, pwd)
cur.execute(sql)
# 若 pwd 输入 ' OR '1'='1，语句变成 WHERE name='x' AND pass='' OR '1'='1'
还有基于时间的盲注，即使页面不回显数据，攻击者可利用 SLEEP(5) 等函数判断条件真假，逐字符猜解数据。这些示例共同说明：只要拼接发生且未做类型约束或语句预编译，系统就处于危险中。接下来看怎样从工程上消灭这类写法。
使用预处理语句与输入校验的防范方案
根治SQL注入的标准做法是预处理语句（Prepared Statement）。它的核心是把SQL模板先发给数据库编译，占位符仅接收纯数据，不再参与指令解析。以PHP的PDO为例，代码如下，无论用户输入什么字符，都会被当作id字段的值而非SQL代码。
<?php
$stmt = $pdo->prepare("SELECT title, content FROM article WHERE id = ?");
$stmt->execute([$_GET['id']]);
$row = $stmt->fetch();
// 即使 id 为 "1; DROP TABLE article" 也只会被当做字符串查询，不会执行第二条语句
?>
除了预处理，对整数型参数做强制类型转换也是低成本防线，例如 (int)$_GET['id'] 能从语言层面剔除非法字符。对于必须拼表的动态排序字段，应使用白名单映射，禁止用户直接传列名。同时关闭生产环境SQL报错回显，改为记录日志，避免给攻击者提供线索。
在架构层面，还可以采用ORM框架，它通常默认使用占位符，并封装了常用过滤逻辑。但需注意ORM不等于绝对安全，原生SQL接口若被误用仍会引入注入。综上，理解原理、坚持预处理、辅以校验与最小权限账号，才能系统性降低风险。