SQL注入防护必须采用数据库权限隔离与应用参数化执行双保险，禁用字符串拼接，动态部分需白名单校验，SQL模板须Git版本管控并脱敏审计，权限应最小化且定期核查。
SQL注入防护不能只靠代码层过滤
应用层的 htmlspecialchars 或简单字符串替换（比如把 ' 换成 ''）在复杂查询或 Unicode 编码绕过场景下极易失效。真正能扛住批量扫描和定制化 payload 的，是数据库侧的权限隔离 + 应用侧的参数化执行双保险。任何只在 ORM 调用前加一层正则校验的方案，上线后三个月内大概率被绕过。
必须用预编译语句，且禁止拼接 SQL 字符串
这是唯一被所有主流数据库驱动验证过的可靠方式：
-
MySQLi::prepare()、PDO::prepare()、pg_query_params()等接口强制将参数与 SQL 结构分离，数据库引擎在解析阶段就锁定语法树，变量值仅作为数据传入，无法改变执行逻辑 - 所有动态部分（表名、字段名、ORDER BY 字段、LIMIT 偏移量）都不能进
prepare()的参数占位符，必须走白名单校验或服务端枚举映射 - 错误示例：
"SELECT * FROM users WHERE id = " . $_GET['id']—— 即使$_GET['id']过了 is_numeric() 也危险，因为 MySQL 允许1 OR SLEEP(1)这类数值型布尔盲注
建立 SQL 审计日志并接入版本控制
不是记录“谁查了什么”，而是记录“哪段代码生成了哪条可执行 SQL”：
- 在 DAO 层统一拦截
execute()/query()调用，提取原始 SQL 模板（不含参数值）+ 调用栈 + 关联 Git commit hash - 将模板存入 Git 仓库的
/sql-audit/目录，每次变更需 PR + DBA 复核，禁止直接推送 - 配置 CI 流水线检查新增 SQL 模板是否含
CONCAT(、EXEC(、||（Oracle）、pg_sleep等高危模式 - 审计日志本身要脱敏：参数值用
[REDACTED]替代，但保留类型（如INT、VARCHAR(32)），便于回溯类型不匹配引发的隐式转换漏洞
权限最小化必须落到数据库用户粒度
应用连接数据库时用的账号，不能是 root 或 dbo：
- 创建专用账号，只授予必要表的
SELECT/INSERT/UPDATE，禁用DELETE和DROP（软删除用状态字段代替） - 禁用存储过程执行权限，除非明确需要且已审计过源码 ——
EXECUTE PROCEDURE是常见绕过点 - PostgreSQL 中启用
row_level_security，MySQL 8.0+ 启用CREATE VIEW限制，防止攻击者通过视图构造子查询泄露数据 - 定期用
SELECT grantee, privilege_type FROM role_table_grants（PostgreSQL）或SHOW GRANTS FOR 'app'@'%'（MySQL）核对权限是否漂移
SQL 注入的持久化防护，核心不在“堵”，而在“限”和“溯”。最常被忽略的是：SQL 模板的 Git 版本与线上实际执行语句不一致，或者审计日志里参数类型丢失导致无法识别 0x75736572（hex 编码的 "user"）这类绕过。这些细节一旦松动，整个防护链就从根上断了。
