Django防SQL注入与ORM参数化查询详解

Django ORM 默认通过参数化查询天然防御SQL注入，但一旦使用raw()、extra()、cursor.execute()等绕过ORM的原生SQL操作，安全防线便立即失效——此时必须严格采用显式参数绑定（如%s占位符配合params传参），严禁字符串拼接；LIKE模糊匹配需手动转义通配符，动态表名、字段名、排序字段等非值类参数则必须通过白名单校验，而非依赖用户输入。真正危险的不是技术盲区，而是误以为“用了Django就绝对安全”而疏忽了那些游离于QuerySet之外的手写SQL逻辑。

用 Django ORM 就不会 SQL 注入？

绝大多数情况下，是的——但前提是别绕过 ORM 的参数化机制。Django 的 filter()、get()、exclude() 等 QuerySet 方法默认使用参数化查询，底层交给数据库驱动做绑定变量处理，原始 SQL 中的值永远不会拼接到字符串里。

容易踩的坑是：以为“用了 Django”就绝对安全，结果在不该用字符串格式化的地方硬塞变量。

• 别用 f"SELECT * FROM user WHERE name = '{name}'" 或 "WHERE name = '%s'" % name
• 别用 extra(where=[f"name = '{name}'"]) —— where 参数不自动转义
• 别用 raw() 时直接插变量：User.objects.raw("SELECT * FROM auth_user WHERE username = '%s'" % username)

Django raw() 和 extra() 怎么安全传参？

raw() 和 extra() 是 ORM 中少数允许写原生 SQL 的入口，也是 SQL 注入高发区。它们都支持显式参数绑定，但语法不同、行为有差异。

用 raw() 必须用 params 关键字传元组或字典，且只认 %s 占位符（PostgreSQL/SQLite/MySQL 都兼容）：

User.objects.raw("SELECT * FROM auth_user WHERE username = %s AND is_active = %s", params=["alice", True])

extra() 的 where 不接受 params，但 tables、joins 等也不该由用户输入控制；真要动态条件，应改用 Q 对象或把过滤逻辑移到 filter() 中。

• raw() 的 params 是唯一安全方式，%s 不能换成 {} 或 :name
• extra(where=...) 里的字符串如果含用户输入，必须手动调用 connection.ops.adapt_unknown_value()（不推荐，难维护）
• SQLite 下 raw() 不支持命名参数（如 %(name)s），统一用位置参数 %s

自定义 Manager 或 raw SQL 中怎么处理 LIKE 模糊匹配？

LIKE 查询常被忽略转义问题：用户输入的 %、_ 会被数据库当通配符执行，这不是注入，但属于逻辑漏洞（比如搜 %admin% 匹配到所有用户名含 “admin” 的记录）。Django 不自动处理 LIKE 转义，得手动加 escape 字符。

正确做法是用 __contains、__icontains 等字段查找，它们由 ORM 自动转义并生成带 ESCAPE 的 SQL；若必须用 raw()，需显式指定 escape：

User.objects.raw("SELECT * FROM auth_user WHERE username LIKE %s ESCAPE '\\'", params=["\\%alice\\%"])

• __search（全文索引）和 __regex 同样不自动转义用户输入，需预处理
• 用 connection.cursor() 执行原生 SQL 时，也必须走 cursor.execute(sql, params)，不能用 .format() 或 % 拼接
• PostgreSQL 的 ILIKE 和 MySQL 的 LOWER() 包裹也不能绕过参数绑定

第三方包或数据库视图会不会绕过 ORM 防护？

会。只要最终执行的是拼接出来的 SQL 字符串，ORM 的防护就失效。典型场景包括：用 django-sql-explorer 允许用户写查询、用 django-pivot 动态生成报表 SQL、或对接 PostgreSQL 视图时在 view definition 里硬编码了用户字段名。

这些地方的“输入”不是 Django 的 request.GET，而是配置项、模型字段名、排序字段（order_by 参数）、甚至分表后缀。它们不经过 QuerySet 的参数化流程，必须单独校验。

• 排序字段必须白名单校验：if sort_field not in ["username", "email", "date_joined"]: 再用 order_by(sort_field)
• 动态表名/字段名不能来自 request，应映射为内部枚举或配置键
• 用 cursor.execute() 时，哪怕只传一个整数 ID，也要放进 params 元组，不要写成 f"WHERE id = {id}"

最危险的不是不懂怎么防，而是忘了哪段代码没走 QuerySet —— 尤其是老项目里混着 raw SQL、cursor、和手写的管理命令。

以上就是《Django防SQL注入与ORM参数化查询详解》的详细内容，更多关于的资料请关注golang学习网公众号！