分布式系统全局防御SQL注入攻击的完整方案

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

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

只要项目中存在execute或query方法可以接受原始字符串+参数数组/对象的组合，就存在被绕过的风险。举个例子，Node.js 的 pg 库虽然支持 client.query('SELECT * FROM users WHERE id = $1', [id]) 这种安全写法，但一旦有人误用 client.query(`SELECT * FROM users WHERE id = ${id}`)，防线瞬间就破了。

• 在 Ja va 项目中，要检查所有 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"这件事在代码库里变得显眼、难以隐藏、容易被扫描到——这才是真正的防御之道。