别再只盯着SQLmap了！手把手教你用Django的QuerySet方法复现CVE-2022-28346
深入解析Django ORM安全陷阱：从CVE-2022-28346看QuerySet的潜在风险
在Web开发领域，Django以其强大的ORM（对象关系映射）系统著称，让开发者能够用Python代码而非原始SQL语句操作数据库。然而，正是这种便利性，往往让开发者忽视了ORM底层可能存在的安全隐患。2022年曝光的CVE-2022-28346漏洞，就是一个典型的案例——它揭示了Django框架中annotate()、aggregate()和extra()等高级QuerySet方法可能导致的SQL注入风险。
这个漏洞的特殊之处在于，它并非源于开发者直接拼接SQL语句，而是由于ORM自身对特定查询构造的处理不当。对于正在使用或学习Django的中高级开发者来说，理解这类漏洞的成因和防范措施，远比单纯掌握漏洞复现步骤更为重要。本文将带你从Django ORM的安全设计原理出发，通过代码级分析，揭示那些看似安全的ORM操作背后可能隐藏的陷阱。
1. Django ORM的安全机制与潜在漏洞面
Django ORM被广泛认为能自动防止SQL注入，这主要得益于它的参数化查询机制。当我们使用基本的filter()、get()等方法时，ORM会将Python值与SQL语句分离处理：
# 安全的参数化查询示例 User.objects.filter(username=request.GET['username'])这种情况下，即使用户输入包含SQL特殊字符，ORM也会正确处理转义。然而，Django提供的一些高级查询方法，为了满足复杂查询需求，会在安全机制上开一些"后门"。
1.1 危险方法深度解析
以下是Django ORM中需要特别警惕的几个方法：
| 方法名 | 典型用途 | 风险等级 | 潜在危险场景 |
|---|---|---|---|
extra() | 注入原始SQL片段 | 高 | where/tables参数 |
raw() | 执行原始SQL查询 | 高 | 直接拼接用户输入 |
annotate() | 添加聚合注解 | 中 | 使用Func()表达式时的参数处理 |
aggregate() | 执行聚合计算 | 中 | 键名或表达式处理 |
order_by() | 指定排序字段 | 低 | 直接使用用户输入作为字段名 |
CVE-2022-28346漏洞特别聚焦于annotate()方法在与特定聚合函数结合使用时的问题。开发者通常会认为这些高级方法是框架提供的安全抽象，却忽视了它们在某些边界条件下的行为。
关键安全原则：任何允许SQL片段或表达式直接插入查询管道的方法，都需要视为潜在风险点，即使它们来自Django的标准库。
2. CVE-2022-28346漏洞的代码级解剖
这个漏洞的核心在于Django的django.db.models.aggregates.Aggregate类实现。当使用annotate()配合某些聚合函数时，攻击者可以构造特定输入，导致SQL注入。
2.1 漏洞触发条件
要复现这个漏洞，需要满足以下环境配置：
- Django 3.2.x < 3.2.13
- Django 4.0.x < 4.0.4
- 使用PostgreSQL或Oracle作为数据库后端
漏洞复现的基本代码模式如下：
from django.db.models import Count # 危险用法 - 用户可控的聚合别名 queryset.annotate( vuln_col=Count(request.GET['alias_name']) )2.2 漏洞原理分析
查看Django的补丁代码，可以发现问题出在聚合函数处理列名的方式上。在旧版本中，Aggregate类的resolve_expression()方法没有对列名进行充分验证：
# 漏洞代码简化示意（补丁前） def resolve_expression(self, query, allow_joins=True, reuse=None, summarize=False): # 缺少对self.source_expressions的严格校验 c = self.copy() c.is_summary = summarize for expr in c.source_expressions: expr.resolve_expression(query, allow_joins, reuse, summarize) return c攻击者可以通过精心构造的alias_name参数，注入恶意SQL片段。例如，传入"1)) AS vuln_col FROM auth_user WHERE (1=1"这样的值，会导致生成的SQL语句结构被破坏。
3. 安全复现环境搭建与漏洞验证
为了在不影响生产环境的情况下研究这个漏洞，我们可以使用Docker快速搭建隔离的测试环境。
3.1 环境配置步骤
- 创建隔离的Django项目：
mkdir django-sqli-test && cd django-sqli-test python -m venv venv source venv/bin/activate pip install django==3.2.12 psycopg2-binary- 准备docker-compose.yml文件：
version: '3' services: db: image: postgres:13 environment: POSTGRES_PASSWORD: postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - "8000:8000" depends_on: - db- 创建有漏洞的视图代码：
# vuln_app/views.py from django.db.models import Count from django.http import JsonResponse def vulnerable_view(request): from myapp.models import User queryset = User.objects.all() # 危险：直接使用用户输入作为聚合参数 result = queryset.annotate( malicious=Count(request.GET.get('field', 'id')) ).values('malicious') return JsonResponse(list(result), safe=False)3.2 漏洞验证方法
启动环境后，可以构造以下请求进行测试：
curl "http://localhost:8000/vuln/?field=1))%20FROM%20auth_user%20WHERE%201=1%20--"如果返回了非错误响应，且包含了不应存在的数据，则验证漏洞存在。安全版本的Django会抛出django.db.utils.DatabaseError异常。
4. 安全编码实践与防御策略
理解了漏洞成因后，我们需要建立系统的防御策略，而不仅仅是修复这一个特定问题。
4.1 Django ORM安全使用清单
输入验证层：
- 对所有用户提供的字段名、表名参数进行白名单验证
- 使用Django内置的
sanitize_separators处理路径分隔符
安全API选择：
# 安全替代方案示例 from django.db.models import Q # 不安全的做法 # queryset.extra(where=["name = '%s'" % name]) # 安全做法 queryset.filter(Q(name=name))ORM配置最佳实践：
- 始终使用最新稳定版Django
- 在settings.py中启用：
DEBUG = False # 防止敏感信息泄露 DATABASES = { 'default': { 'OPTIONS': { 'options': '-c statement_timeout=1000' # 设置查询超时 } } }
4.2 安全审计工具集成
对于大型项目，建议在CI/CD管道中加入静态分析工具：
# 使用bandit进行安全扫描 pip install bandit bandit -r . -x venv -ll典型的安全扫描应该检查以下模式：
- 所有使用
extra()、raw()的地方 - 任何动态拼接的查询条件
- 从请求对象直接获取的字段名参数
在开发过程中，我曾经遇到一个案例：一个看似无害的报表功能，因为使用了extra(select={'user_input': request.GET['calc']})，导致了二阶SQL注入。这个问题直到安全审计时才被发现，凸显了全面检查的重要性。
5. 从漏洞复现到安全开发思维转变
真正的安全不是靠工具或框架的"自动防护"，而是开发者在每个设计决策中的安全意识。对于Django开发者来说，这意味着：
- 深度理解ORM原理：不只是会使用API，还要明白它们生成的SQL结构
- 最小权限原则：数据库用户应该只有必要的最低权限
- 纵深防御：在ORM层之外，添加WAF、定期安全扫描等保护措施
当我们需要复杂查询时，更安全的做法是使用Django的表达式API：
from django.db.models import F, Func # 安全的自定义函数用法 class SafeExtract(Func): function = 'EXTRACT' template = '%(function)s(%(expressions)s FROM %(field)s)' queryset.annotate( year=SafeExtract('year', field='created_at') )这种模式既保持了灵活性，又通过Django的查询表达式机制确保了安全性。在我的多个项目实践中，这种模式成功平衡了功能需求和安全要求。