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` 轻量检测），验证防护是否生效
基本上就这些。防护不是 堆技巧，而是建立“输入不进语法层”的思维习惯。参数化是地基，权限是围墙，校验是门禁，监控是巡更——各司其职，才能高效又安全地处理数据。
