SQL注入防护：不只是参数化查询，数据库层面还能做什么——问题探讨

参数化查询（预编译）几乎是所有人聊 SQL 注入防护时先搬出来的“黄金法则”。这当然没错：把用户输入当作数据而不是 SQL 代码，确实能挡住绝大多数注入。但在真实项目里，历史代码、动态表名、排序字段、报表工具、ORM 的 raw SQL、存储过程里的字符串拼接，仍可能让注入找到缝隙。于是问题来了：除了应用层参数化，数据库层面还能做什么？

先抛一个观点：数据库层不是用来替代参数化查询的，而是用来构建纵深防御的。参数化是底线，最小权限、访问控制、审计、防火墙、安全配置则是提高攻击成本、限制爆炸半径的关键。下面按几个方向展开。

参数化查询为什么不是终点

参数化只能保护“值”，保护不了“标识符”。比如 `ORDER BY` 后面的列名、`LIMIT` 的数量、动态表名，很多框架并不支持绑定，只能拼接。如果这些位置来自用户输入，仍然可能被利用。再比如存储过程内部用 `EXEC('SELECT ...' + @input)`，或者 ORM 里直接拼 SQL，参数化就绕过了。所以，数据库层面必须假设应用层可能失守。

最小权限：最朴素也最有效

应用连接数据库的账号，绝不该是 root、sa 或 dbo。按业务拆分账号：只读账号、写入账号、报表账号、后台管理账号。只授予必要的库、表、列和操作，禁止 `DROP`、`ALTER`、`GRANT`，禁止访问 `mysql.user` 等敏感元数据。限制连接来源 IP，把数据库放在内网，只允许应用服务器访问。这样即使注入成功，攻击者能做的也极其有限。

细粒度访问控制：视图、存储过程与行级安全

用视图暴露必要列，隐藏敏感字段；用存储过程封装查询逻辑，但内部同样要参数化。PostgreSQL 的行级安全（RLS）、Oracle 的 VPD、SQL Server 的行级安全，可以让数据库根据会话上下文自动过滤数据。列级权限也值得用起来，避免 `SELECT *` 把不该看的字段全带出去。数据库不该只是“存储桶”，它也可以是权限边界。

数据库防火墙与审计：让异常查询可见

数据库防火墙或代理层可以基于 SQL 语法、访问模式、频率做阻断，比如识别 `UNION SELECT`、注释符、堆叠查询、异常长查询。审计日志要记录所有查询、失败登录、DDL 和权限变更。告警规则可以关注：非工作时间大量 `SELECT`、同一账号短时间报错激增、敏感表被异常访问。注意平衡性能与隐私，但“看不见”才是最大的风险。

安全配置与加固：关掉不该开的功能

禁用 `xp_cmdshell`、`LOAD_FILE`、`INTO OUTFILE`、`pg_read_file` 等危险函数或扩展；限制数据库进程的文件读写权限；统一字符集，避免宽字节注入；设置合适的 `sql_mode`；关闭详细错误回显，应用层统一错误页；禁用多语句，限制堆叠查询；及时打补丁。这些配置不花哨，但能直接砍掉一批攻击面。

连接层与编码：容易被忽视的细节

确保驱动真正启用了预编译，比如 PDO 要设置 `ATTR_EMULATE_PREPARES = false`。不同微服务使用不同数据库账号，连接池隔离。启用 TLS 加密连接，防止凭证和数据被窃听。对于必须动态拼接的标识符，用白名单校验，而不是转义。数据库层和应用层要一起发力。

应急响应与持续验证

定期做权限审计、漏洞扫描、代码审计；用红蓝对抗模拟注入；准备好快速下线账号、阻断 IP、回滚权限的流程。数据库层的防护不是一劳永逸，而是持续运营。

参数化查询是必选项，但不是唯一项。数据库层面能做的最小权限、细粒度访问控制、审计与防火墙、安全加固、监控响应，共同构成纵深防御。它们不能保证 100% 不被注入，但能让攻击者更难成功、更难扩大、更难隐藏。你们团队在数据库层还做了哪些防护？欢迎一起探讨。