Django ORM防注入解析

Django的ORM是防止SQL注入最坚固的防线之一，但前提是你得用对。很多开发者以为用了Django就万事大吉，结果在原生SQL查询、动态字段拼接或者聚合函数里埋下隐患。ORM的核心防护机制是参数化查询，它把用户输入和SQL逻辑彻底分离，让恶意代码无法改变查询结构。但如果你绕过ORM的查询构造器，直接拼接字符串，防护就失效了。理解ORM哪里能保护你、哪里需要额外警惕，才是防注入的真正关键。

Django ORM生成的每条SQL语句，都会把用户输入作为参数传递给数据库驱动，而不是拼接到SQL字符串里。比如User.objects.filter(username=user_input)，最终执行的SQL是SELECT * FROM users WHERE username = %s，其中%s是占位符，数据库驱动会把user_input的值单独传递。这意味着即使user_input包含' OR '1'='1这样的恶意片段，它也会被当作普通字符串处理，不会改变WHERE子句的逻辑。Django使用数据库适配器（如psycopg2、mysqlclient）的预处理语句机制，从协议层面隔离了数据和指令。这种防护是自动的、透明的，只要你使用标准的filter()、exclude()、get()等方法，注入攻击就无从下手。

当你需要复杂SQL时，可能会用到raw()方法。直接拼接字符串在这里是致命的：User.objects.raw(f"SELECT * FROM users WHERE username = '{user_input}'")会完全暴露在注入攻击下。正确的做法是使用参数占位符：User.objects.raw("SELECT * FROM users WHERE username = %s", [user_input])。Django会对params列表里的每个元素进行转义和参数化处理。注意占位符的写法：SQLite和MySQL使用%s，PostgreSQL使用%s也兼容，但最好查阅数据库后端文档。如果raw()查询里需要动态表名或列名，参数化无法处理标识符，这时你必须用白名单校验，绝不能让用户输入直接控制表名或字段名。

extra()曾经是Django ORM中灵活构造查询片段的方式，但它允许直接插入SQL子句，极易被滥用。例如User.objects.extra(where=[f"username = '{user_input}'"])就是典型的注入漏洞。Django官方已在3.0版本中标记extra()为不推荐使用，并计划在未来移除。替代方案是使用annotate()配合RawSQL表达式，或者用Q对象和Func表达式来构建复杂条件。如果你必须维护旧代码中的extra()，务必使用params参数传递用户输入，而不是拼接字符串。迁移到新API不仅能消除注入风险，还能让查询逻辑更清晰、更易维护。

在聚合和注解中，RawSQL表达式让你能嵌入原生SQL片段，同时保留参数化能力。写法是User.objects.annotate(custom_field=RawSQL("CASE WHEN username = %s THEN 1 ELSE 0 END", [user_input]))。这里%s占位符同样受到保护。但要注意，RawSQL的第一个参数是原始SQL字符串，如果你在这个字符串里拼接了用户输入，防护就失效了。始终把动态值放在第二个参数的列表里。另外，RawSQL返回的是数据库端的计算结果，如果用于ORDER BY或GROUP BY，需要确保表达式本身不会引入注入点，因为排序和分组子句通常不支持参数化，这时要对动态字段名做严格的白名单过滤。

Django的Func类让你能调用数据库函数，比如Length、Lower等。自定义Func时，模板字符串里不要直接嵌入用户输入。例如class MyFunc(Func): function = 'MY_FUNC'; template = "%(function)s(%(expressions)s, '%(user_input)s')"这种写法是危险的。正确的做法是让用户输入作为表达式参数传入，Django会将其转为参数化占位符。你可以重写as_sql()方法，但务必使用self.extra或参数化机制。如果函数参数只能是字面量，考虑在Python层面对输入做严格校验，或者使用数据库的绑定变量功能。记住，任何进入SQL字符串的用户数据都必须经过ORM的参数化通道。

有些业务场景需要根据用户选择来排序或筛选不同字段，比如order_by(user_input)。Django的order_by()和filter({field_name: value})在展开关键字参数时会验证字段名是否存在于模型中，这提供了一定程度的保护。但如果你用字符串格式化构造关键字参数，比如filter({f"{field_name}__icontains": value})，field_name部分仍然可能被注入恶意字符。最佳实践是维护一个允许的字段名白名单，用户输入必须与白名单匹配后才能使用。对于表名，绝对不要从用户输入中获取，Django的模型系统已经抽象了表名，跨表查询应使用关联对象或select_related()、prefetch_related()。

当你需要执行完全自定义的SQL时，django.db.connection.cursor()是最后的手段。游标的execute()方法同样支持参数化：cursor.execute("SELECT * FROM users WHERE username = %s", [user_input])。但executemany()和execute()在处理多语句时行为不同，某些数据库驱动默认禁止多语句执行，这能防止经典的; DROP TABLE攻击。不要使用cursor.execute("SELECT ... WHERE username = '%s'" % user_input)这种字符串格式化。另外，游标操作后要记得关闭，或者使用with connection.cursor() as cursor:上下文管理器。原生SQL意味着你放弃了ORM的模型保护，必须自己确保每条语句都参数化。

即使你确信代码安全，也应该在开发和测试阶段启用Django的查询日志，检查实际执行的SQL。在settings中配置LOGGING，将django.db.backends的日志级别设为DEBUG，就能看到所有数据库操作。如果日志中出现用户输入直接嵌入SQL字符串的情况，那就是潜在漏洞。生产环境可以使用数据库的审计功能或第三方APM工具来监控异常查询模式。Django的connection.queries列表在DEBUG模式下会记录所有查询，但注意它只保存有限数量，且在生产环境会消耗大量内存。定期用安全扫描工具检查代码中的字符串拼接模式，重点关注raw、extra、RawSQL和cursor.execute的调用。

很多Django第三方库提供了额外的查询集方法或管理器，它们内部可能使用原生SQL。使用前要审查源码，看是否有字符串拼接用户输入的情况。特别是那些提供全文搜索、地理空间查询或复杂聚合功能的库，它们为了性能常常绕过ORM构造器。如果你使用的库版本较老，可能存在已知的注入漏洞，保持依赖更新很重要。对于自定义的QuerySet方法，如果内部调用了extra()或拼接SQL，要立即重构为参数化形式。代码审查时，任何包含f"...{user_input}..."或"..." + user_input + "..."的数据库查询都应该亮红灯。

ORM的参数化是最后一道防线，但前端验证能减少恶意输入到达数据库的机会。Django的表单和序列化器提供了类型校验、长度限制和格式验证，这些应该在数据进入查询之前就完成。例如，一个预期为整数的字段，先用IntegerField清洗，再传给ORM，这样即使有注入企图，也会在类型转换阶段被拦截。但不要依赖前端验证作为安全措施，攻击者可以直接构造HTTP请求绕过浏览器验证。Django的cleaned_data机制在服务端执行，是可靠的第一关。结合ORM的参数化，形成纵深防御，让注入攻击的成功率降到零。

很多人认为filter(id__in=user_list)是安全的，确实如此，因为Django会将列表展开为参数化占位符。但如果你手动构造in子句的字符串部分，比如raw("SELECT * FROM users WHERE id IN (%s)" % ','.join(user_list))，就引入了注入风险。正确的raw()写法是raw("SELECT * FROM users WHERE id IN %s", [tuple(user_list)])，注意这里占位符对应的是一个元组，Django会正确处理。另一个误区是exclude()，它的行为与filter()相反，但同样安全。只要你不把用户输入拼接到Q对象的字符串表示里，exclude()就是参数化的。

不同数据库对参数化占位符的支持略有差异。SQLite使用?，但Django统一为%s，由后端适配器转换。MySQL的mysqlclient驱动支持%s，而PostgreSQL的psycopg2使用%s或%(name)s命名参数。Django的ORM抽象了这些差异，但当你写原生SQL时，应该始终使用%s作为占位符，并传递列表或元组作为参数。不要使用Python的字符串格式化操作符%来替换用户输入，那是完全不同的概念。另外，某些数据库的LIKE子句需要转义通配符%和_，Django的filter(field__contains=value)会自动处理，但原生SQL中你需要手动转义，这虽然不是注入，却是数据准确性的问题。

ORM的参数化保护仅限于SQL查询层面。如果你的应用在存储过程、数据库视图或触发器中使用了动态SQL，ORM无法保护那些部分。存储过程内部如果拼接字符串执行动态查询，同样存在注入风险。Django调用存储过程时，即使传入参数是安全的，过程内部的漏洞仍然会被触发。因此，审查数据库层的代码同样重要。此外，ORM不能防止二阶SQL注入，即恶意数据先存储到数据库，后续被其他查询读取并拼接到SQL中。如果你在某个地方从数据库取出用户之前提交的数据，然后用于构造另一个查询的SQL字符串，就会产生二阶注入。始终对所有进入SQL的数据保持参数化，无论数据来源是用户直接输入还是数据库已有记录。

Django ORM的防注入能力强大但并非魔法。它在你遵循框架约定时提供坚不可摧的保护，在你偏离轨道时则毫无防备。理解参数化查询的本质、知道哪些API是安全的、哪些需要额外小心，以及如何安全地使用原生SQL，这些知识比盲目信任框架更重要。代码审查时关注字符串拼接、动态字段名和原生查询调用，配合查询日志监控，就能构建起真正可靠的防注入体系。