Django的开发团队致力于负责报告和披露安全相关问题。因此，我们采用并遵循了一套符合这一理想的政策，旨在使我们能够及时向德江哥的官方发行版以及第三方发行版提供安全更新。
简短版本：请通过电子邮件security@djangoproject.com报告安全问题 .
Django中的大多数正常错误都报告给 our public Trac instance 但是由于安全问题的敏感性，我们要求他们 not 以这种方式公开报道。
相反，如果您认为您在Django发现了安全隐患，请通过电子邮件将问题描述发送至 security@djangoproject.com . 发送到该地址的邮件到达 security team .
一旦您通过电子邮件提交问题，您应该在3个工作日内收到安全团队成员的确认。之后，安全团队将开始分析。根据要采取的行动，您可能会收到后续电子邮件。安全团队可能需要几周时间才能得出结论。除非您发现新的相关信息，否则无需追捕安全团队。所有报告均旨在在行业标准的90天内得到解决。已确认漏洞 high severity level 将立即解决。
发送加密报告
如果你想发送加密邮件（ 可选择的 ）的公钥ID security@djangoproject.com 是 0xfcb84b8d1d17f80b ，此公钥可从最常用的密钥服务器获得。
请私下分享一个最小的Django项目或代码片段来演示潜在的漏洞。包括有关如何设置、运行和重现问题的明确说明。
请不要附上代码截图。
基于未能清理用户输入的报告不是有效的安全漏洞。正确处理用户输入是开发人员的责任。这一原则在我们的 security documentation .
例如，以下是 not considered valid 因为 email 尚未消毒：：
from django.core.mail import send_mail
from django.http import JsonResponse
def my_proof_of_concept(request):
email = request.GET.get("email", "")
send_mail("Email subject", "Email body", email, ["admin@example.com"])
return JsonResponse(status=200)
开发人员必须 always validate and sanitize input 在使用它之前。正确的方法是使用Django表格来确保 email 已正确验证：：
from django import forms
from django.core.mail import send_mail
from django.http import JsonResponse
class EmailForm(forms.Form):
email = forms.EmailField()
def my_proof_of_concept(request):
form = EmailForm(request.GET)
if form.is_valid():
send_mail(
"Email subject",
"Email body",
form.cleaned_data["email"],
["admin@example.com"],
)
return JsonResponse(status=200)
return JsonResponse(form.errors, status=400)
同样，作为Django的原始SQL结构（例如 extra() 和 RawSQL 表达）为开发人员提供了对查询的完全控制，如果用户输入没有得到正确处理，他们就不安全。正如我们的解释 security documentation ，开发人员有责任安全地处理这些函数的用户输入。
例如，以下是 not considered valid 因为 query 尚未消毒：：
from django.shortcuts import HttpResponse
from .models import MyModel
def my_proof_of_concept(request):
query = request.GET.get("query", "")
q = MyModel.objects.extra(select={"id": query})
return HttpResponse(q.values())
为了防止拒绝服务（DPS）攻击，生产级服务器对请求标头和URL大小施加了限制。例如，默认情况下Gunicorn允许大约：
4k bytes for a URL _
8K bytes for a request header _
其他网络服务器，例如Nginx和Apache，也有类似的限制，以防止过度消耗资源。
因此，Django安全团队不会考虑依赖于超过8 K字节的请求标头或URL的报告，因为此类输入已经在生产环境中的服务器级别得到了缓解。
runserver 永远不应该用于生产
Django的内置开发服务器不强制执行这些限制，因为它不是为生产服务器而设计的。
的 DATA_UPLOAD_MAX_MEMORY_SIZE 设置将默认最大请求正文大小限制为2.5 MB。
由于默认情况下这对所有生产级Django项目都强制执行，因此请求正文中的概念证明不得超过2.5 MB才被视为有效。
应使用 public ticket tracker 用于硬化。
概念验证必须可能发生在生产级Django应用程序中，反映现实世界的场景并遵循标准开发实践。
Django包含许多私有和未记录的函数，这些函数不属于其公共API的一部分。如果漏洞依赖于以不安全的方式直接调用这些内部函数，则不会被视为有效的安全问题。
Django模板语言（DTL）旨在构建显示网页所需的内容。特别是它的文本过滤器旨在用于这种用途。
供参考，莎士比亚全集的纯文本ASC编码约有350万字节。在单个请求中进行此类访问几乎超出了所有网站的范围，因此也超出了DTL的范围。
文本处理是昂贵的。Django不保证DTL文本过滤器在传递精心制作的足够大的输入时不会受到性能下降的影响。在默认配置下，Django使网站很难意外地接受来自不可信来源的此类负载，但是，如果需要显示大量用户提供的内容，则采取基本的安全措施非常重要。
用户提供的内容应始终限制在已知的最大长度。应对其进行过滤以删除恶意内容，并对其进行验证以匹配预期格式。如果有必要，在显示之前应该离线处理它。
DTL使用超过100 KB数据处理的概念证明将被视为无效。
这些是安全团队在评估报告是否需要安全发布时使用的标准：
该漏洞位于 supported version 姜戈的。
该漏洞不依赖于依赖Django外部代码的手动操作。这包括项目开发人员或维护人员使用开发人员工具或Django CLI执行的操作。例如，需要运行具有不常见或不安全选项的管理命令的攻击不符合资格。
该漏洞适用于生产级Django应用程序。这意味着以下情况不需要安全发布：
只影响当地发展的利用，例如使用 runserver .
未能遵循安全最佳实践的漏洞利用，例如未能对用户输入进行清理。有关其他示例，请参阅我们的 security documentation .
利用人工智能生成的代码不遵守安全最佳实践。
安全团队可能会得出结论，漏洞的来源位于Python标准库中，在这种情况下，报告者将被要求向Python核心团队报告该漏洞。欲了解更多详细信息，请参阅 Python security guidelines .
有时，可能会发布安全版本来帮助解决流行的第三方包中的安全漏洞。这些报告应该来自包维护者。
如果您不确定您的发现是否符合这些标准，请仍然报告 privately by emailing security@djangoproject.com .安全团队将审查您的报告并建议正确的行动方案。
在任何时候，Django团队都会为几个版本的Django提供官方安全支持：
这个 main development branch ，托管在GitHub上，这将成为Django的下一个主要版本，得到安全支持。只影响主开发分支而不影响任何稳定发布版本的安全问题是公开修复的，无需经过 disclosure process 。
最近的两个Django发行系列获得了安全支持。例如，在导致Django 1.5发布的开发周期中，将为Django 1.4和Django 1.3提供支持。Django 1.5发布后，Django 1.3的安全支持将结束。
Long-term support release S将在指定的时间段内接收安全更新。
当出于安全原因发布新版本时，随附的通知将包括受影响版本的列表。此列表仅包含 支持 Django的版本：旧版本也会受到影响，但我们不会调查以确定这一点，也不会为这些版本发布补丁或新版本。
安全漏洞的严重程度由攻击类型决定。
严重程度级别为：
High
远程代码执行
SQL注入
Moderate
跨站点脚本（XSS）
跨站点请求伪造（CSRF）
阻断服务攻击
损坏的身份验证
Low
敏感数据暴露
中断的会话管理
未验证的重定向/转发
需要特殊配置选项的问题
我们从私下讨论到公开披露安全问题的过程涉及多个步骤。
大约在公开披露前一周，我们会发送两份通知：
首先，我们通知|姜戈宣布|即将发布的安全版本的日期和大致时间，以及问题的严重程度。这是为了帮助需要确保有工作人员来处理我们的公告分类并根据需要升级Django的组织。
第二，我们通知 people and organizations 主要由操作系统供应商和Django的其他经销商组成。此电子邮件使用某人的pgp密钥签名，该密钥来自 Django's release team 包括：
对问题和受影响版本的Django的完整描述。
我们将采取的补救措施。
将应用于Django的修补程序（如果有）。
Django团队将应用这些补丁、发布新版本和公开披露该问题的日期。
在披露日，我们将采取以下步骤：
将相关补丁应用于Django的代码库。
发布相关新闻稿(S)，将新包放置在 Python Package Index 以及在 djangoproject.com website ，并在Django的Git库中标记新版本(S)。
在上发布公共条目 the official Django development blog 详细描述该问题及其解决方案，指出相关补丁和新版本，并将该问题归功于报告人（如果报告人希望公开确认）。
向django announce和oss-security@lists.openwall.com邮件列表发布通知，链接到博客文章。
如果一个报告的问题被认为是特别敏感的——例如，由于野外已知的剥削——提前通知和公开披露之间的时间可能会大大缩短。
此外，如果我们有理由相信报告给我们的问题会影响到python/web生态系统中的其他框架或工具，我们可以与适当的维护人员私下联系和讨论这些问题，并与他们协调我们自己的披露和解决方案。
Django团队还保持 archive of security issues disclosed in Django .
收到安全问题预先通知的人员和组织的完整列表不会公开，也不会公开。
我们还旨在尽可能有效地减少该列表，以便在披露之前更好地管理机密信息的流动。因此，我们的通知列表是 not 只是Django的用户列表，作为Django的用户并不足以成为被置于通知列表中的理由。
从广义上讲，安全通知的接收者分为三类：
提供适当通用（即， not 个人的个人电子邮件地址）用于报告他们的django软件包问题的联系地址，或用于一般安全报告的联系地址。在任何一种情况下，此类地址 不能 转发到公共邮件列表或bug跟踪程序。可接受转发到个人维护者或安全响应联系人的私人电子邮件的地址，尽管强烈建议使用私人安全跟踪者或安全响应组。
根据具体情况，对这些通知作出响应并负责任地采取行动的各个包维护人员。
根据Django开发团队的判断，需要逐案了解未决安全问题的其他实体。通常，该集团的成员将包括一些最大的和/或最有可能受到严重影响的Django已知用户或分销商，并且需要证明能够负责任地接收、保密并对这些通知采取行动。
安全审计和扫描实体
作为政策，我们不会将这些类型的实体添加到通知列表中。
如果您认为您或您被授权代表的组织属于上面列出的组之一，您可以通过电子邮件请求添加到Django的通知列表中。 security@djangoproject.com . 请使用主题行“安全通知请求”。
你的要求 must 包括以下信息：
您的全名、真实姓名以及您所代表的组织的名称（如果适用），以及您在该组织中的角色。
关于您或您的组织如何符合上面列出的至少一组标准的详细说明。
有关您请求安全通知的原因的详细解释。再说一遍，请记住这是 not 只需一个Django用户列表，绝大多数用户应该订阅Django Announce以提前收到安全发布时间的通知，而不需要提供问题的详细信息，而不是请求详细通知。
您希望添加到通知列表中的电子邮件地址。
关于谁将接收/审查发送到该地址的邮件的说明，以及有关将要采取的任何自动操作的信息（即，在错误追踪器中归档机密问题）。
对于个人，与您的地址相关联的公钥ID，可用于验证从您收到的电子邮件，并根据需要加密发送给您的电子邮件。
提交后，Django开发团队将考虑您的请求；您将在30天内收到通知您请求结果的回复。
请记住，对于任何个人或组织，接收安全通知是由Django开发团队自行决定授予的特权，可以随时取消此特权，无论是否有解释。
提供所有所需信息
在决定是否批准您的请求时，未能在初始联系中提供所需信息将对您不利。
5月 28, 2025