Django作为一个Python高可用性，高安全性框架，披露出的安全漏洞也是少之又少，因此成为了Python开发者开发站点的不二之选。Django的代码审计也是相对于其他语言框架较为困难的一款，其中一个因素为Python没有返回和传入类型的检查，并且Django内置函数名重复地非常多，甚至连Pycharm都无法准确定位到具体函数当中，代码审计也变得异常艰难。除去Django官方网站披露的CVE漏洞之外，本文主要谈一谈如何发现Django官方没有披露的潜在漏洞以及高效查看潜在问题的代码块。
Django announce
Django官方有着与其他框架相同的版本预告通知，同时Django会提前预报未来发布漏洞更新的时间以及漏洞等级，因此我们可以根据漏洞发出时间第一时间进行漏洞分析和响应
https://groups.google.com/g/django-announce
Django Commit
遍历Django历史上评级为高的漏洞，不难发现基本上全都是SQL注入的漏洞，例如CVE-2022-34265, CVE-2022-28346, CVE-2021-35042, CVE-2020-9402等。Django对参数过滤是非常严格的，但是正是因为严格化导致部分参数因为过滤无法正常运行。因此，为了保证功能有效运行，就不得不去除对该参数的过滤，这也为Django埋下了隐患。因此对关注Django commit中关于SQL操作的代码进行审计并查看参数是否被函数封装往往能有意想不到的效果。
从笔者之前分析的CVE-2021-35042，具体内容可以查看文章 https://xz.aliyun.com/t/9834。其漏洞代码最早可以追述到3年前的issue，对函数add\_ordering的传参内容过滤忽略RawSQL函数中col参数的过滤了导致的SQL注入，commit的链接为 https://github.com/django/django/pull/12669/files。以及CVE-2020-9402等等也都是忽略了对某template参数的过滤导致的漏洞的产生，具体分析文章链接为https://xz.aliyun.com/t/7403。查看对数据库操作的test测试样例也是一种不错的方法。
Django ticket
Django ticket是Django官方用来追踪问题所用的平台，同时也是很多开发者报告问题的平台。因此这里也有一些开发者报告的BUG而官方认为是漏洞，以及一些安全研究者上报的漏洞被官方认为是feature，因此发布在ticket里面。在这些对安全的讨论中，都出现了如下关键词"security team"，"security issue"以及"security@..."，因此我们可以使用Google搜索语法对这些讨论帖子做搜索
`intext:"security" inurl:"code.djangoproject.com/ticket/"`` ``intext:"security issue"|"security issues" inurl:"code.djangoproject.com/ticket/"`
例如
上述ticket报告了Django使用dbshell的时候报错会带出数据库的密码等敏感信息，但是Django安全团队认为这不算是一个安全问题，但是研究者也给出了应用场景：在使用Elastic、Graylog等组件的时候，有时候不能对--password进行混淆，因此会导致敏感信息泄漏。
同时也能看到开发者并不认为是安全问题的组件最终被定义为安全问题，例如CVE-2020-24583文件权限。起初该问题只是被开发者认为是一个bug，但最终被Django 安全团队定义为漏洞
完整ticket连接如下
https://code.djangoproject.com/ticket/31921
其实浏览Django tickets讨论的feature也有着意想不到的收获