直接用参数化查询替换所有拼接SQL是根治SaaS平台SQL注入的唯一方式，因多租户、多数据源、多数据库方言及复杂输入场景下，过滤、转义等手段极易被绕过或引发兼容问题。
直接用参数化查询替换所有拼接 SQL 的地方，是唯一能根治 SaaS 平台 SQL 注入的方式。其他手段（如过滤关键字、转义单引号）在多租户、多数据库类型、多客户端输入源的 SaaS 场景下，极易被绕过或引发兼容性问题。
为什么 SaaS 环境下拼接 SQL 特别危险
SaaS 平台通常具备以下特征，让传统“简单过滤”完全失效：
- 租户数据混存在同一张表（靠
tenant_id隔离），攻击者一旦注入成功，可能跨租户读取或篡改他人数据 - 用户输入来源复杂：API 请求体、URL 查询参数、Webhook 回调、第三方集成字段（如 Slack payload、CRM 同步字段）都可能进 SQL
- 数据库方言不统一：PostgreSQL 的
$1占位符、MySQL 的?、SQL Server 的@param，混用字符串拼接时极易漏掉某类查询 - ORM 也不保险：Django 的
extra()、Rails 的find_by_sql、Laravel 的DB::raw()都会绕过 ORM 的参数化保护
必须全局禁用的危险操作模式
在 SaaS 代码库中，以下写法应被 CI/CD 流水线直接拦截或标记为高危：
- 任何含
+ " WHERE user_id = " + user_id或.format(...)拼接 SQL 字符串的地方 -
mysql_query("SELECT * FROM orders WHERE status = '" + status + "'")类 PHP 原生函数调用 - Node.js 中使用
pg.query("UPDATE users SET name = '" + name + "'")（未用$1占位符） - Java 中
Statement.execute("DELETE FROM logs WHERE id IN (" + ids + ")")—— 即使ids是数组转成的字符串，也已失守
参数化查询落地时的关键细节
光“用了参数化”不等于安全，SaaS 场景下必须校验以下三点：
- 动态表名/列名不能参数化 → 必须走白名单校验：
if table_name not in ['users', 'orders', 'invoices']: raise SecurityError - ORDER BY 子句中的字段名和方向（ASC/DESC）也不能参数化 → 用枚举映射：
sort_map = {'created': 'created_at', 'name': 'full_name'}，再拼接 - IN 查询需动态占位符数量 → 不要手写
(?, ?, ?)，用语言原生支持方式生成，例如 Python 的tuple(params)配合','.join(['%s'] * len(params)) - PostgreSQL 数组参数（如
WHERE id = ANY($1)）必须用pg.ARRAY或对应驱动的数组类型传入，不能传字符串
租户隔离层额外加固点
即使所有 SQL 都参数化，SaaS 还需防止租户越权访问——这常被误认为是 SQL 注入修复范围，实则紧密耦合：
- 每个数据库连接应绑定固定
tenant_id，并在所有查询中强制添加AND tenant_id = ?条件（通过 ORM 全局 scope 或中间件自动注入） - 禁止在应用层做“租户 ID 解析后拼接”，例如
"SELECT * FROM " + tenant_schema + ".users"—— schema 名必须来自白名单配置，而非请求头或 cookie - 审计日志中记录执行 SQL 的完整参数值（脱敏后），而不仅是语句模板，便于追溯是否发生参数污染
最易被忽略的是：SaaS 的管理后台、数据导出接口、Webhook 处理逻辑，往往比主业务流更松懈。这些路径一旦存在字符串拼接，就是攻击者最优先爆破的目标。修复必须覆盖全部入口，不能只盯用户注册/登录等显眼模块。
