SQL注入防护的核心是断开输入与执行逻辑的绑定，首选参数化查询；辅以输入校验、最小权限原则、WAF与日志监控，构建多层防御体系。
SQL注入防护的核心是不让用户输入直接拼接到SQL语句中。关键不在“堵漏洞”，而在“断开输入与执行逻辑的绑定”。下面从实操角度讲清楚怎么防、怎么优。
用参数化查询代替字符串拼接
这是最根本、最有效的防护手段。数据库驱动（如MySQLi、PDO、JDBC）都支持预编译+占位符，让输入只作为数据传入，不参与SQL语法解析。
- ✅ 正确写法（PDO示例）：`$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ? AND status = ?"); $stmt->execute([$user, $status]);`
- ❌ 危险写法：`"SELECT * FROM users WHERE username = '$user' AND status = '$status'"` —— 单引号也挡不住恶意闭合
- 注意：即使用了`addslashes()`或`mysql_real_escape_string()`（已废弃），也不能替代参数化，它们只是转义，不是隔离执行逻辑
严格校验和过滤输入，但不依赖它防注入
输入校验是辅助层，目的是早发现异常、提升可读性，但它不能作为SQL注入的主防线（因为业务规则复杂，过度限制会影响功能）。
- 对ID类字段：用`is_numeric()`或正则`/^\d+$/`确认纯数字
- 对用户名、邮箱等：定义白名单字符集（如`/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/`），拒绝非法字符
- 对排序字段（如`ORDER BY name ASC`中的`name`）：绝不直接代入，应映射为白名单键值，例如`$sortMap = ['name'=>'username', 'time'=>'created_at']; $col = $sortMap[$input] ?? 'id';`
最小权限原则 + 权限分离
数据库账号权限越小，被攻破后的危害越低。别让Web应用用root或DBA账号连库。
- Web服务账号只授予所需表的`SELECT/INSERT/UPDATE`权限，禁用`DROP`、`ALTER`、`LOAD_FILE`、`UNION SELECT ... INTO OUTFILE`等高危操作
- 管理后台、定时任务、API服务使用不同账号，按功能切分权限
- 生产环境关闭数据库错误回显（如MySQL的`show_errors=OFF`），避免泄露表结构或路径信息
引入WAF与日志监控作补充防线
参数化+权限控制是内功，WAF（Web应用防火墙）和审计日志是外防+哨兵，三者协同更稳。
- 部署开源WAF如ModSecurity，配置SQL注入规则集（如OWASP CRS），拦截典型payload（`' OR 1=1--`、`UNION SELECT`等）
- 记录所有带用户输入的SQL执行日志（脱敏后），重点关注报错日志、高频失败查询、非预期的`UNION`/`BENCHMARK`/`SLEEP`调用
- 定期用工具扫描（如sqlmap加`--risk=1 --level=2`轻量检测），验证防护是否生效
基本上就这些。防护不是堆技巧，而是建立“输入不进语法层”的思维习惯。参数化是地基，权限是围墙，校验是门禁，监控是巡更——各司其职，才能高效又安全地处理数据。
