1. Django SQL注入漏洞CVE-2022-28346深度解析
作为一名长期从事Web安全研究的从业者，我最近在复现Django框架的一个高危SQL注入漏洞（CVE-2022-28346）时，发现虽然官方早已发布补丁，但许多开发者对这个漏洞的成因和危害仍然认识不足。本文将基于vulfocus靶场环境，详细剖析这个漏洞的技术细节，并通过完整的实验过程演示漏洞利用方式。
这个漏洞影响范围包括：
- Django 2.2系列 < 2.2.28
- Django 3.2系列 < 3.2.13
- Django 4.0系列 < 4.0.4
漏洞的核心在于QuerySet的annotate()、aggregate()和extra()方法在处理列别名时，未能正确过滤通过**kwargs传入的字典参数，导致攻击者可以构造恶意输入实现SQL注入。
2. 漏洞环境搭建与初步探测
2.1 实验环境准备
我使用的是vulfocus提供的django-cve_2022_28346:latest靶机镜像，这是一个预先配置好的漏洞环境。启动后访问http://ip:port即可看到演示页面。
重要提示：所有安全测试必须在授权环境下进行，本文仅用于技术研究，请勿用于非法用途。
2.2 初始页面分析
访问首页后，我们能看到一个简单的演示应用。通过观察页面元素和网络请求，可以发现几个关键点：
- URL结构为/demo?field=demo.name，表明后端可能通过field参数动态构建查询
- 页面返回的数据格式表明后端使用Django ORM进行数据库操作
- 尝试修改field参数的值，观察系统响应变化
2.3 错误页面信息收集
故意访问不存在的路径触发404页面，这里发现一个重要线索：错误页面显示了Django的调试信息，包括：
- 使用的Django版本（确认在受影响范围内）
- 项目目录结构
- 可能的视图函数命名
这些信息对后续的漏洞利用至关重要，特别是在真实环境中，这类调试信息往往会暴露系统内部细节。
3. 漏洞原理深度剖析
3.1 技术背景：Django ORM工作机制
Django的ORM（对象关系映射）是其核心组件之一，它允许开发者使用Python代码而非直接编写SQL来操作数据库。常见的查询方法包括：
- annotate(): 添加注解/聚合值
- aggregate(): 对整个查询集进行聚合
- extra(): 注入额外的SQL片段
这些方法在构建查询时，会将Python字典参数转换为SQL语句的列别名部分。
3.2 漏洞具体成因
问题出在列别名的处理逻辑上。当使用**kwargs传递参数时，如：
python复制Demo.objects.annotate(**{"random name": SomeFunc()})
Django会将这些参数用于构建SQL语句的AS部分。正常情况下，列别名应该是简单的标识符，但Django未对输入进行充分过滤，导致攻击者可以通过精心构造的字典键名注入恶意SQL代码。
3.3 漏洞触发条件分析
要使这个漏洞被成功利用，需要满足以下条件：
- 应用使用受影响版本的Django
- 代码中使用annotate()/aggregate()/extra()方法
- 这些方法的参数通过用户可控的**kwargs传入
- 未对用户输入进行严格过滤
在实际审计中，需要特别关注从请求参数直接构建ORM查询的场景。
4. 漏洞利用实战演示
4.1 基础注入测试
通过修改field参数，我们可以初步验证漏洞存在性：
原始请求：
code复制http://ip:port/demo?field=demo.name
测试注入：
code复制http://ip:port/demo?field=demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" --
这个payload的工作原理是：
- 闭合原始查询的列名部分
- 通过UNION注入额外的查询
- 使用--注释掉后续可能干扰的SQL片段
4.2 数据库信息收集
成功注入后，我们可以通过以下方式获取数据库信息：
- 数据库版本：sqlite_version()
- 表结构查询：
code复制SELECT name FROM sqlite_master WHERE type='table' - 特定表数据：
code复制SELECT * FROM auth_user
4.3 高级利用技巧
在实际渗透测试中，还可以尝试：
- 使用CASE WHEN条件判断进行盲注
- 通过load_extension加载外部库（需配置允许）
- 写入webshell（需有写权限）
- 利用SQLite的ATTACH DATABASE功能跨库查询
注意：这些高级技术可能对系统造成更大影响，必须在授权测试中谨慎使用。
5. 漏洞修复方案
5.1 官方补丁分析
Django官方通过以下方式修复了该漏洞：
- 对列别名进行严格的标识符验证
- 禁止在别名中使用特殊字符和SQL关键字
- 添加了额外的参数过滤层
修复commit主要修改了：
- django/db/models/sql/query.py
- django/db/models/aggregates.py
5.2 升级建议
受影响用户应立即升级到以下安全版本：
- Django 2.2.28+
- Django 3.2.13+
- Django 4.0.4+
升级命令：
bash复制pip install --upgrade django==4.0.4
5.3 临时缓解措施
如果暂时无法升级，可以考虑：
- 对用户输入进行严格过滤
- 避免直接将用户输入传递给**kwargs
- 使用Django内置的过滤和验证机制
- 限制数据库用户的权限
6. 防御措施与最佳实践
6.1 安全编码建议
- 永远不要信任用户输入
- 使用Django内置的参数化查询
- 最小化数据库账户权限
- 禁用调试模式的生产环境
6.2 安全审计要点
在代码审查时，需要特别关注：
- 所有使用annotate()/aggregate()/extra()的地方
- 任何从请求参数直接构建查询的场景
- 动态构建字典作为**kwargs传入ORM方法的情况
6.3 监控与检测
建议实施以下安全监控：
- 记录异常的SQL查询模式
- 监控UNION、SELECT等关键字的出现
- 定期扫描依赖库的漏洞信息
7. 经验总结与思考
在实际测试过程中，我遇到了几个值得分享的问题：
- 不同Django版本的具体表现可能有差异，需要针对性调整payload
- SQLite和MySQL等不同后端数据库的注入技术有所不同
- 生产环境往往没有详细的错误信息，需要盲注技术
这个漏洞再次提醒我们，即使是成熟的框架也可能存在严重的安全问题。作为开发者，我们需要：
- 保持框架和依赖库的及时更新
- 深入理解所用技术的安全特性
- 建立完善的安全开发和审计流程
最后，我想强调的是，安全研究应该遵循负责任的披露原则。发现漏洞后，应该首先通知相关厂商，给予合理的修复时间，而不是立即公开或利用漏洞进行非法活动。