Python后端防SQL注入：ORM与原生SQL方案解析

SQL注入绝非小概率风险，而是只要存在字符串拼接就必然发生的严重安全漏洞——无论是在日志打印中短暂出现用户输入，还是在ORM的extra()、raw()或原生SQL的f-string、format()中嵌入变量，都等同于主动拆除防护网；真正可靠的防御只有一条铁律：所有数据值必须通过数据库驱动原生支持的参数化查询（如psycopg2用%s、sqlite3用?）严格传递，且参数必须为元组或列表；表名、列名、排序字段等无法参数化的动态部分则须通过白名单校验严加控制；任何自定义转义函数、字符串替换或“看似安全”的拼接技巧，不仅无效，反而会制造虚假安全感，掩盖本质风险——参数化不是可选项，而是唯一经得起实战检验的生命线。

SQL注入不是“可能出问题”，而是只要拼接字符串就一定会出问题——哪怕只在日志里打印一次用户输入后又塞进 cursor.execute()，风险就已经存在。

用 ORM 时，filter() 和 get() 是安全的，但 extra()、raw() 不是

Django 或 SQLAlchemy 的常规查询方法（如 User.objects.filter(username=username)、session.query(User).filter(User.name == name)）底层自动走参数化，你传进去的变量不会被解释为 SQL 结构。

但一旦调用：

• Django 的 extra()、raw()、annotate() 中嵌入字符串表达式
• SQLAlchemy 的 text()、select().where(text("..."))
• 或任何带 f-string、%、+ 拼接的 SQL 片段

那就等于亲手拆掉防护网。比如：

qs = User.objects.extra(where=["username = '%s'" % request.GET.get('u')]) —— 这行代码和裸写 execute() 一样危险。

关键判断点：只要 SQL 字符串里出现了单引号包裹的变量、或用了 Python 字符串格式化，就不是参数化，就是高危。

sqlite3、psycopg2、pymysql 的参数占位符不通用

不同驱动对参数占位符的语法要求不同，硬写错一个符号就会绕过参数化机制，变成拼接：

• sqlite3 只认 ? 或命名参数 :name，不支持 %s
• psycopg2（PostgreSQL）只认 %s（位置）或 %(name)s（命名），不支持 ?
• pymysql（MySQL）只认 %s，且必须是英文百分号，不能是中文或全角

常见错误：

cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,)) —— 在 PostgreSQL 上会报 TypeError: not all arguments converted，但更糟的是：有人发现报错后，顺手改成 "%s" 并继续用字符串拼接，以为“只是语法问题”。

正确做法是查清驱动文档，严格匹配占位符；别靠猜，也别复用其他数据库的写法。

原生 SQL 必须用 execute() + 参数元组，不能用 format() 或 f-string

哪怕你只查一个字段、只传一个参数，只要用了字符串格式化，就等于把门钥匙交给攻击者：

❌ 错误：cursor.execute(f"SELECT * FROM logs WHERE ip = '{ip}'")
❌ 错误：cursor.execute("SELECT * FROM logs WHERE ip = '{}'".format(ip))
✅ 正确：cursor.execute("SELECT * FROM logs WHERE ip = %s", (ip,))（psycopg2）
✅ 正确：cursor.execute("SELECT * FROM logs WHERE ip = ?", (ip,))（sqlite3）

注意：

• 参数必须是元组或列表，单个值记得加逗号：(ip,)，不是 (ip)（后者是括号，不是元组）
• 占位符不能出现在表名、列名、ORDER BY 子句中——这些地方无法参数化，需白名单校验或 re.match(r'^[a-zA-Z][a-zA-Z0-9]*$', user_input) 严格过滤

自定义 SQL 转义函数是伪安全，别自己写 escape_sql()

网上有些“防注入工具函数”像这样：

def escape_sql(s): return s.replace("'", "''").replace('"', '""')

这只能应付极简场景，且对 PostgreSQL 的 $$ 块、MySQL 的反引号标识符、Unicode 引号变体完全无效。更严重的是：它给人“已防护”的错觉，反而掩盖了真正该用参数化的地方。

真正的边界很清晰：

• 表名/列名/排序方向 → 白名单控制（例如 if order_field not in ('created_at', 'score'): raise Http404）
• 动态条件字段 → 用 ORM 的 Q 对象组合，或预定义 SQL 模板 + 参数化值部分
• 其他一切数据值 → 只走驱动原生参数化接口，不碰字符串拼接

参数化不是“可选项”，是唯一经过验证的防御路径。任何绕开它的“转义”“过滤”“替换”，都只是给漏洞披了层薄纱。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~