在分布式系统中怎样全局防御SQL注入攻击？

全局防御SQL注入需在各层设防：必须全程使用参数化查询，落实最小权限数据库账号，禁用所有动态SQL拼接路径，并通过WAF、AST扫描、白名单校验等多手段协同防护。

全局防御 SQL 注入，不是靠某一层加个过滤器就能解决的——它必须在数据流转的每个关键节点设防，且各层防御不能互相抵消或绕过。核心是：参数化查询必须贯穿所有数据库访问点，最小权限账号必须落实到每个服务实例，而任何动态拼接 SQL 的路径（比如日志归档、分库分表路由、审计写入）都得被显式识别并禁用。

所有数据库客户端必须强制使用参数化查询

只要存在 execute 或 query 方法接受原始字符串 + 参数数组/对象的组合，就极易被绕过。比如 Node.js 的 pg 库支持 client.query('SELECT * FROM users WHERE id = $1', [id])，但若有人误用 client.query(`SELECT * FROM users WHERE id = ${id}`)，就直接破防。

• Java 侧检查所有 Statement.execute()、Statement.executeQuery() 调用，禁止传入拼接字符串；只允许 PreparedStatement + setXxx()
• Python 项目中禁用 cursor.execute("SELECT ... %s" % value) 和 f"SELECT ... {value}"，CI 流水线加入 AST 扫描规则（如 semgrep 规则 python.lang.security.sql-injection）
• Go 的 database/sql 中，db.Query(fmt.Sprintf(...)) 是高危模式，必须用 db.Query("SELECT ... WHERE id = ?", id)
• MyBatis 用户注意：${} 是字符串替换，等同于拼接，哪怕只用于表名也危险；#{} 才是预编译，但无法用于列名/表名——这类动态结构应走白名单校验，而非放行

每个微服务连接数据库时必须使用独立最小权限账号

一个服务连库用 app_order_reader，另一个用 app_user_writer，不是为了管理方便，而是让任意服务被注入后，攻击者最多只能读订单表或改用户表，无法跨域操作。

• MySQL 中为每个服务建账号，只 GRANT SELECT ON order_db.orders TO 'app_order_reader'，不授 information_schema 写权限，也不给 USAGE 以外的全局权限
• PostgreSQL 中避免用 public schema 授权，明确 GRANT SELECT ON TABLE orders TO app_order_reader，并确保该角色不在 pg_catalog 上有 SELECT 权限（除非真需要查系统表）
• Kubernetes 环境下，账号密码通过 Secret 注入，禁止硬编码或存入 ConfigMap；ServiceAccount 绑定的 RBAC 不应包含对数据库凭证资源的读权限
• 验证方式：登录该账号后执行 DROP TABLE IF EXISTS fake;，必须返回 permission denied；执行 SELECT * FROM pg_tables WHERE schemaname = 'pg_catalog'; 应报错或空结果

中间件与网关层需识别并拦截 DDL 类关键词（仅作兜底）

WAF 或 API 网关拦截 CREATE、DROP、ALTER 不是为了替代权限控制，而是防住那些漏掉的、非业务路径上的漏洞（比如调试接口、旧版管理后台、未下线的测试路由）。

• 腾讯云 WAF、Cloudflare Rules 或 OpenResty + lua-resty-waf 都可配置正则规则，匹配 b(DROP|CREATE|ALTER|TRUNCATE|EXEC|xp_cmdshell)b（注意大小写和空格边界）
• 不要依赖简单关键字黑名单：攻击者可用 %20DROP%0aTABLE、/**/DROP/**/TABLE 或十六进制编码绕过；应启用语义解析引擎（如 WAF 的 AI 模式）
• 重点监控响应体含 mysql_fetch_array、psycopg2.ProgrammingError、ORA-00900 等错误信息的请求，这类暴露式错误本身就会助推盲注
• 日志中出现连续多个含 UNION SELECT、SLEEP(5)、AND 1=1 的请求，应自动触发 IP 封禁，而非仅告警

ORM 和分库分表组件容易成为隐性缺口

很多团队以为用了 MyBatis 或 Hibernate 就万事大吉，但分库分表中间件（如 ShardingSphere、Vitess）或自研路由逻辑，常常在 SQL 解析、重写、下发阶段重新拼接语句——这里一旦出问题，前面所有参数化都白搭。

• ShardingSphere 的 sql.parser.cache 默认开启，但若配置了 sql.show=true 且日志输出原始 SQL，可能意外泄露拼接痕迹；生产环境必须关闭
• Vitess 的 VSchema 若定义了动态表名映射，后端生成 SQL 时若用 fmt.Sprintf("SELECT * FROM %s", tableName)，就等于开了后门
• 自研分表路由务必校验表名是否在白名单内（如 orders_202406、orders_202407），禁止接受 orders; DROP TABLE users-- 这类输入
• 所有 SQL 构建逻辑必须经过统一的 SQLSanitizer 工具链校验，该工具应能识别占位符是否被真实绑定，而非仅检查字符串里有没有 ?

真正难防的不是 ' OR 1=1 --，而是某个运维脚本、某个离线导出任务、某个灰度环境的 debug 接口，悄悄绕过了主流程的参数化约束。全局防御的关键，是让“拼接 SQL”这件事在代码库里变成一件显眼、难隐藏、易被扫描到的异类行为。