Django的extra()方法和raw SQL查询是开发者直接执行SQL语句的两种方式，但它们都可能成为SQL注入的入口。extra()允许在QuerySet中插入特定的SQL子句，而raw()则用于执行原始SQL查询。如果开发者未对用户输入进行严格过滤，攻击者就能通过构造恶意输入来篡改SQL逻辑，导致数据泄露或破坏。解决方法包括：始终使用参数化查询、避免直接拼接用户输入、利用Django内置的ORM安全方法替代extra()、对raw()查询使用params参数传递安全参数，并实施严格的输入验证和输出编码。

理解Django的extra()方法及其风险

extra()是Django ORM中的一个方法，允许开发者在查询中添加自定义的SQL片段，例如SELECT、WHERE或ORDER BY子句。这在ORM功能不足时提供了灵活性，但也是危险的来源。例如，如果开发者使用extra()来动态插入用户提供的字段名或条件，而未经验证，就可能被注入。假设有一个查询根据用户输入排序：

User.objects.extra(select={'custom_field': "name"}, where=["email = %s" % user_input])

这里，如果user_input是恶意字符串如"' OR '1'='1'"，SQL语句会被篡改，导致所有用户数据泄露。extra()本身不提供参数化机制，因此直接拼接字符串极易引发漏洞。Django官方文档已标记extra()为遗留方法，建议避免使用，因为它破坏了ORM的抽象层，增加了维护和安全隐患。

raw SQL查询中的注入点分析

raw()方法用于执行原始SQL查询，返回Django模型实例。它虽然强大，但同样需要谨慎处理。例如，一个简单的raw查询：

User.objects.raw("SELECT * FROM auth_user WHERE username = '%s'" % username)

如果username来自用户输入且未过滤，攻击者可以输入"admin' --"来注释掉后续查询，或联合其他表窃取数据。raw()的风险在于开发者可能误以为Django会自动转义输入，但实际上，只有在使用params参数时才会安全处理。Django的raw()支持参数化，类似其他数据库接口，但必须显式使用，否则字符串拼接直接暴露注入点。

SQL注入的具体攻击场景示例

在Django中，注入可能发生在Web应用的任何接收输入处，如表单、URL参数或API端点。考虑一个场景：应用使用extra()构建搜索功能，where子句包含用户搜索词。攻击者输入"'; DROP TABLE auth_user; --"，这可能导致整个用户表被删除。对于raw()查询，如果执行复杂报表生成，动态拼接表名或列名，如"SELECT * FROM %s" % table_name，攻击者可能通过输入"auth_user; SELECT * FROM sensitive_data"来执行多条语句，具体取决于数据库后端支持。这些攻击不仅泄露数据，还可能破坏应用完整性。

预防extra()注入的最佳实践

首先，尽量避免使用extra()。Django ORM已覆盖大多数查询场景，如使用annotate()进行聚合、F()表达式进行字段操作。如果必须使用extra()，确保不直接嵌入用户输入。对于静态SQL片段，硬编码在代码中；对于动态部分，使用参数化方式。Django的extra()支持params参数，但文档中较少强调，正确用法是：

User.objects.extra(where=["email = %s"], params=[user_input])

这样，user_input会被安全转义。此外，实施严格的输入验证：只允许预期字符（如字母数字），并使用Django的验证器或正则表达式过滤。例如，对于字段名，可以白名单方式限制为已知安全选项。

确保raw SQL查询安全的方法

使用raw()时，必须始终用params参数传递用户输入。正确示例：

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

这里，%s是占位符，Django会根据数据库后端自动转义参数。注意，占位符格式可能因数据库而异（如PostgreSQL用%s，SQLite用?），但params机制统一处理。另外，避免动态构建SQL结构（如表名），如果必需，应在代码层映射：例如，用字典将用户选项映射到预定义表名。同时，限制查询权限：数据库用户应只有最小必要权限，避免执行DROP或ALTER等危险操作。

结合ORM和自定义查询的混合策略

在复杂应用中，有时ORM无法满足性能或功能需求，这时可以混合使用安全raw查询和ORM。例如，先用raw()执行复杂JOIN，但用params传递条件；然后结果与ORM对象交互。Django的raw()返回模型实例，可以继续使用ORM方法。另一个策略是使用cursor()执行低级SQL，但同样要参数化：

from django.db import connection
with connection.cursor() as cursor:
    cursor.execute("SELECT * FROM auth_user WHERE id = %s", [user_id])

这提供了更大控制，但要求开发者手动处理结果。无论哪种方式，都应编写单元测试，模拟恶意输入来验证安全性。

行业趋势和替代工具建议

随着Django版本更新，extra()逐渐被废弃，社区推荐使用更安全的表达式API，如Func()、Window()等。对于高级SQL需求，可以考虑使用第三方库如django-sql-utils或直接优化ORM查询。同时，静态代码分析工具（如Bandit）可以扫描项目中的extra()和raw()使用，标记潜在注入点。作为行业分析师，我观察到现代Web开发更强调“纵深防御”：除了参数化查询，还应实施WAF（Web应用防火墙）、定期安全审计和依赖更新。Django的内置安全功能很强，但开发者需主动启用，如设置SECURE设置、使用HTTPS，并教育团队关于注入的风险。

总结：构建无注入的Django应用

总之，Django的extra()和raw SQL是双刃剑：提供灵活性的同时引入注入风险。核心解决方案是永远不信任用户输入，并坚持参数化查询。在开发流程中，代码审查应重点关注SQL拼接点；生产环境应记录和监控异常查询模式。通过遵循这些原则，开发者可以充分利用Django的威力，同时保持应用坚固安全。记住，安全不是一次性任务，而是持续的过程，从设计到部署都需贯彻始终。