sql注入测试需绕过orm自动转义，重点检测原始字符串拼接、动态标识符白名单校验、多数据库语法差异及mock时真实sql捕获。
SQL注入测试必须绕过ORM的自动转义
很多团队误以为用了 SQLAlchemy 或 Django ORM 就天然防注入，其实不然——只要代码里拼接了原始字符串再交给数据库驱动执行，风险就存在。比如用 text() + execute()、或直接调用 cursor.execute(sql, params) 但把用户输入塞进 sql 字符串里（而非 params），就等于主动拆掉防护。
实操建议：
- 在测试中构造典型恶意输入：
"' OR 1=1 -- "、"; DROP TABLE users; --、"' UNION SELECT password FROM users -- " - 不要只测返回结果是否为空，要检查实际执行的 SQL 是否被完整传入（可通过 mock
cursor.execute或启用 DB 日志捕获） - 若使用
psycopg2，注意%s占位符必须配合参数元组/字典传入；写成f"WHERE name = '{name}'"就是硬伤
动态表名/列名无法用参数化，必须白名单校验
参数化查询对表名、列名、排序字段（ORDER BY xxx）、分页偏移（LIMIT ?, ? 中的第一个 ?）完全无效。这类动态部分必须提前约束，否则测试再全也拦不住注入。
实操建议：
- 提取可接受的表名列名列表，例如：
ALLOWED_TABLES = {"users", "orders", "products"}，在拼接前强制校验if table_name not in ALLOWED_TABLES: raise ValueError - 测试用例要覆盖边界：传入
"users; DROP TABLE admins"、"users--"、"USERS"（大小写绕过）、"user\x00s"（空字节截断） - 避免用
str.lower()后比对——某些数据库（如 PostgreSQL）对标识符大小写敏感，而校验逻辑可能漏掉引号包裹的双引号标识符（"UsErS"）
测试需覆盖不同数据库的语法差异
同一段“看似安全”的拼接逻辑，在 MySQL、PostgreSQL、SQLite 上可能表现不同。比如 MySQL 支持 /* */ 注释、PostgreSQL 支持 || 字符串拼接、SQLite 对单引号转义更宽松——测试若只跑 SQLite，很可能漏掉真实环境的风险。
实操建议：
- 单元测试中启动轻量级内存 DB 实例（如
sqlite:///:memory:）仅够验证逻辑；真正防注入必须在 CI 中并行跑 PostgreSQL 和 MySQL 容器 - 重点验证注释绕过：
"user' -- comment"在 PostgreSQL 中会注释掉后续条件，但在某些 MySQL 模式下可能报错或被忽略 - 留意数据库驱动对特殊字符的预处理——例如
pyodbc对;的默认行为可能和psycopg2不同，测试时得用真实 driver
Mock 数据层时别绕过 SQL 构建逻辑
为提速而 mock session.execute 或 cursor.execute 是常见做法，但如果 mock 直接返回假数据、跳过 SQL 拼接过程，那就等于没测防御逻辑本身。
实操建议：
- mock 应拦截并记录实际传入的
sql字符串和params，再断言sql中不包含用户输入原文（例如 assert "' OR 1=1" not in captured_sql） - 对使用
text()的场景，mocktext()构造函数，检查其参数是否含未过滤变量（如text(f"SELECT * FROM {table}")） - 避免 patch 错层级：patch
sqlalchemy.engine.Engine.execute比 patchyour_module.query_users更接近真实执行路径
真正的难点不在写几个 payload，而在于确认 SQL 字符串在到达数据库驱动前的那一刻，是否已被净化或隔离——所有中间环节（ORM 封装、自定义 query builder、DB wrapper 类）都得暴露出来被观测。
