Django 的安全策略

Django 开发团队坚定地致力于负责任地报告和披露与安全相关的问题。因此,我们已经采用并遵循了一套符合这一理想的策略,这些策略旨在使我们能够及时向 Django 的官方发行版以及第三方发行版提供安全更新。

报告安全问题

简而言之:请通过电子邮件 security@djangoproject.com 报告安全问题。.

大多数 Django 中的普通错误都会报告给我们公开的 Trac 实例,但由于安全问题的敏感性,我们要求不要以这种方式公开报告它们。

相反,如果您认为在 Django 中发现了存在安全隐患的问题,请通过电子邮件发送问题的描述到security@djangoproject.com。发送到该地址的邮件会到达安全团队

通过电子邮件提交问题后,您应该会在 48 小时内收到安全团队成员的确认,并且根据要采取的操作,您可能会收到后续的电子邮件。

发送加密报告

如果您想发送加密电子邮件(可选),security@djangoproject.com 的公钥 ID 为 0xfcb84b8d1d17f80b,并且此公钥可从大多数常用的密钥服务器获取。

Django 如何评估报告

以下是安全团队在评估报告是否需要安全发布时使用的标准

  • 漏洞存在于受支持的 Django 版本中。

  • 漏洞适用于生产级 Django 应用程序。这意味着以下情况不需要安全发布

    • 仅影响本地开发的漏洞利用,例如使用runserver时。

    • 未能遵循安全最佳实践的漏洞利用,例如未能对用户输入进行清理。有关其他示例,请参阅我们的安全文档

    • AI 生成的代码中不符合安全最佳实践的漏洞利用。

安全团队可能会得出结论,漏洞的根源在于 Python 标准库,在这种情况下,将要求报告者向 Python 核心团队报告该漏洞。有关更多详细信息,请参阅Python 安全指南

有时,可能会发布安全版本以帮助解决流行的第三方软件包中的安全漏洞。这些报告应来自软件包维护者。

如果您不确定您的发现是否符合这些标准,请仍然通过电子邮件私下向 security@djangoproject.com 报告。安全团队将审查您的报告并推荐正确的行动方案。

受支持的版本

在任何给定时间,Django 团队都会为几个版本的 Django 提供官方安全支持。

  • 托管在 GitHub 上的主开发分支将成为 Django 的下一个主要版本,它将获得安全支持。仅影响主开发分支而不影响任何稳定发布版本的安全问题会在公开修复,而不会经过披露流程

  • 最近的两个 Django 发布系列将获得安全支持。例如,在发布 Django 1.5 的开发周期中,将为 Django 1.4 和 Django 1.3 提供支持。发布 Django 1.5 后,Django 1.3 的安全支持将结束。

  • 长期支持版本将在指定期限内获得安全更新。

当出于安全原因发布新版本时,随附的通知将包含受影响版本的列表。此列表仅包含 Django 的受支持版本:较旧的版本也可能受到影响,但我们不会进行调查以确定这一点,也不会为这些版本发布补丁或新版本。

Django 如何披露安全问题

我们将安全问题从私下讨论到公开披露的过程涉及多个步骤。

在公开披露前大约一周,我们会发送两封通知

首先,我们会通知django-announce即将发布的安全版本的日期和大致时间,以及问题的严重程度。这将帮助需要确保有员工能够处理我们的公告并根据需要升级 Django 的组织。严重级别如下:

    • 远程代码执行

    • SQL 注入

    • 跨站点脚本 (XSS)

    • 跨站点请求伪造 (CSRF)

    • 拒绝服务攻击

    • 身份验证失效

    • 敏感数据泄露

    • 会话管理失效

    • 未经验证的重定向/转发

    • 需要不常见配置选项的问题

其次,我们会通知一个人员和组织列表,主要由操作系统供应商和 Django 的其他分发者组成。这封电子邮件使用来自Django 发布团队成员的 PGP 密钥签名,并包含:

  • 问题的完整描述和受影响的 Django 版本。

  • 我们将采取的措施来解决该问题。

  • 将应用于 Django 的补丁(如果有)。

  • Django 团队将应用这些补丁、发布新版本和公开披露问题的日期。

在披露当天,我们将采取以下步骤

  1. 将相关补丁应用于 Django 的代码库。

  2. 发布相关版本,方法是在Python 包索引djangoproject.com 网站上放置新软件包,并在 Django 的 git 存储库中标记新版本。

  3. Django 官方开发博客上发布公开条目,详细描述问题及其解决方案,指向相关的补丁和新版本,并感谢问题报告者(如果报告者希望公开识别)。

  4. django-announceoss-security@lists.openwall.com邮件列表中发布指向博客文章的通知。

如果报告的问题被认为特别紧急——例如,由于已知的漏洞在野外存在——提前通知和公开披露之间的时间可能会大大缩短。

此外,如果我们有理由相信向我们报告的问题影响了 Python/Web 生态系统中的其他框架或工具,我们可能会私下联系并与相应的维护者讨论这些问题,并协调我们自己的披露和解决方案。

Django 团队还维护了一个Django 中披露的安全问题的存档

谁会收到提前通知

收到安全问题提前通知的人员和组织的完整列表不会公开,也不会公开。

我们还力求使此列表尽可能小,以便更好地管理披露前机密信息的流程。因此,我们的通知列表不是 Django 用户的简单列表,并且作为 Django 用户不足以成为被列入通知列表的理由。

从广义上讲,安全通知的接收者分为三类

  1. 操作系统供应商和 Django 的其他分发者,他们提供了一个合适的通用(即不是个人的电子邮件地址)联系地址,用于报告其 Django 软件包的问题或进行一般的安全报告。在这两种情况下,此类地址都不得转发到公共邮件列表或错误跟踪器。转发到个人维护者或安全响应联系人私有电子邮件的地址是可以接受的,尽管强烈建议使用私有安全跟踪器或安全响应组。

  2. 在个案基础上,已经证明致力于响应和负责任地处理这些通知的个人软件包维护者。

  3. 在个案基础上,其他实体,在 Django 开发团队的判断下,需要了解即将发生的安全性问题。通常,此组的成员将包括一些最大和/或最有可能受到严重影响的已知 Django 用户或分发者,并且需要证明能够负责任地接收、保密和处理这些通知。

安全审计和扫描实体

根据政策,我们不会将这些类型的实体添加到通知列表中。

请求通知

如果您认为您或您有权代表的组织属于上述组之一,您可以通过发送电子邮件至security@djangoproject.com请求添加到 Django 的通知列表中。请使用主题行“安全通知请求”。

您的请求必须包含以下信息

  • 您的完整真实姓名以及您代表的组织的名称(如果适用),以及您在该组织中的角色。

  • 详细说明您或您的组织如何符合上述至少一组标准。

  • 详细说明您为何请求安全通知。再次提醒您,这不是仅供 Django 用户使用的列表,绝大多数用户应该订阅django-announce以接收安全版本何时发布的提前通知(不包括问题的详细信息),而不是请求详细通知。

  • 您希望添加到通知列表中的电子邮件地址。

  • 解释谁将接收/审查发送到该地址的邮件,以及将采取的任何自动操作的信息(即,在错误跟踪器中提交机密问题)。

  • 对于个人,与您的地址关联的公钥的 ID,该 ID 可用于验证从您收到的电子邮件并根据需要加密发送给您的电子邮件。

提交请求后,Django 开发团队会进行审核;您将在 30 天内收到回复,告知您请求的结果。

请注意,对于任何个人或组织,接收安全通知都是 Django 开发团队自行决定的特权,并且此特权可以随时撤销,无论是否有说明。

提供所有必要信息

如果您在初始联系时未能提供必要的信息,这将对我们是否批准您的请求产生不利影响。

返回顶部