---
title: "Django 的安全策略"
version: 4.2
locale: zh-hans
source: https://docs.djangoproject.com/zh-hans/4.2/internals/security/
canonical: https://djangodocs.dev/zh-hans/4.2/internals/security/
---
# Django 的安全策略

Django的开发团队致力于负责地报告和披露与安全相关的问题。因此，我们采用并遵循了一套符合这种理想的策略，以便及时向Django的官方发行版和第三方发行版发布安全更新。

## 报告安全问题

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

Django 中的大多数普通错误都会报告到 [我们的公共 Trac 实例](https://code.djangoproject.com/query)，但由于安全问题的敏感性质，我们要求不要以这种方式公开报告它们。

相反，如果您认为在 Django 中发现了具有安全影响的问题，请通过电子邮件发送问题描述至 `security@djangoproject.com`。发送到该地址的邮件将会传达给 [安全团队](https://www.djangoproject.com/foundation/teams/#security-team)。

一旦您通过电子邮件提交了问题，您应该会在48小时内收到来自安全团队成员的确认，并根据需要采取的行动，您可能会收到进一步的后续电子邮件。

> **发送加密报告**
>
> 如果您想发送加密邮件（*可选*），`security@djangoproject.com` 的公钥 ID 是 `0xfcb84b8d1d17f80b`，并且这个公钥可以从大多数常用的密钥服务器获取。

## 支持的版本

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

- 在 GitHub 上托管的 [主开发分支](https://github.com/django/django/)，将成为 Django 的下一个主要版本，会接收安全支持。仅影响主开发分支而不影响任何稳定发布版本的安全问题将在公开中修复，无需经过 [披露流程](#security-disclosure)。
- 两个最新的Django发行版系列都提供了安全支持。例如，在Django 1.5发布之前的开发周期中，将支持Django 1.4和Django 1.3。在Django 1.5发布后，Django 1.3的安全支持将结束。
- 长期支持版本 将在指定的期限内接收安全更新。

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

## Django 如何披露安全问题

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

在公开披露前大约一周，我们会发送两个通知：

首先，我们会通知 [django-announce](/zh-hans/4.2/internals/mailing-lists/#django-announce-mailing-list) 关于即将发布的安全更新的日期和大致时间，以及问题的严重性。这是为了帮助需要确保他们有足够人员来处理我们的公告并根据需要升级 Django 的组织。严重性级别包括：

**高**:

- 远程代码执行
- SQL 注入

**中等**:

- 跨站脚本攻击（XSS）
- 跨站请求伪造（CSRF）
- 拒绝服务攻击
- 损坏的认证

**低**:

- 敏感数据暴露
- 会话管理损坏
- 未验证重定向
- 需要不常见的配置选项的问题

其次，我们会通知一份 [个人和组织名单](#security-notifications)，主要由操作系统供应商和其他 Django 分发商组成。此电子邮件由 [Django 发布团队](https://www.djangoproject.com/foundation/teams/#releasers-team) 的某人使用 PGP 密钥签名，内容包括：

- 问题的完整描述以及受影响的Django版本
- 我们将采取的补救措施。
- 补丁(如果有的话)将应用于Django。
- Django 团队将应用这些补丁、发布新版本并公开披露问题的日期。

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

1. 将相关的补丁应用到 Django 的代码库中。
2. 发布相关版本，将新的软件包放在 [Python Package Index](https://pypi.org/project/Django/) 和 [djangoproject.com 网站](https://www.djangoproject.com/download/) 上，并在 Django 的 Git 存储库中标记新版本。
3. 在 [官方 Django 开发博客](https://www.djangoproject.com/weblog/) 上发布一篇公开文章，详细描述问题及其解决方案，指向相关的补丁和新版本，并署名问题的报告者（如果报告者希望公开身份）。
4. 在 [django-announce](/zh-hans/4.2/internals/mailing-lists/#django-announce-mailing-list) 和 [oss-security@lists.openwall.com](mailto:oss-security@lists.openwall.com) 邮件列表上发布一则通知，其中包含指向博客文章的链接。

如果认为报告的问题特别紧急——例如，由于已知有野外利用，提前通知和公开披露之间的时间可能会大大缩短。

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

Django 团队还维护着一个 [Django 中披露的安全问题的档案](/zh-hans/4.2/releases/security/)。

## 谁会收到提前通知

接收安全问题提前通知的个人和组织的完整名单不会被公开。

我们还希望将这个列表尽可能保持较小的规模，以更好地管理披露前的机密信息流动。因此，我们的通知列表并不仅仅是 Django 用户的列表，成为 Django 用户并不足以理由放置在通知列表上。

广义上来说，安全通知的接收者分为三类：

1. 操作系统供应商和其他 Django 分发商，他们提供了一个适合报告他们的 Django 包的问题或用于一般安全报告的通用（即不是个人的个人电子邮件地址）联系地址。在任何情况下，这些地址 **不得** 转发到公共邮件列表或 bug 跟踪器。转发到个人维护人员或安全响应联系人的私人电子邮件的地址是可以接受的，尽管私人安全跟踪器或安全响应组更可取。
2. 根据具体情况，已经表现出对回应和负责任地采取行动的个别包维护者。
3. 根据具体情况，根据 Django 开发团队的判断，其他需要了解即将到来的安全问题的实体。通常，该组成员将包括一些最大的和/或最有可能受到严重影响的已知 Django 用户或分发商，他们需要表现出负责任地接收、保密和采取行动的能力。

> **安全审计和扫描实体**
>
> 作为政策，我们不会将这些类型的实体添加到通知列表中。

## 请求通知

如果您认为自己或您有授权代表的组织属于上述任何一组，您可以通过发送电子邮件至 `security@djangoproject.com` 来请求加入 Django 的通知列表。请在主题行中使用 "Security notification request"。

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

- 您的全名和您所代表的组织的名称（如果适用），以及您在该组织中的角色。
- 详细解释您或您的组织如何符合上述至少一组标准。
- 详细解释您为什么要请求安全通知。请再次注意，这并不仅仅是给 Django 用户使用的列表，绝大多数用户应该订阅 [django-announce](/zh-hans/4.2/internals/mailing-lists/#django-announce-mailing-list) 以提前收到安全发布的通知，而不是请求详细的通知。
- 您希望添加到我们通知列表的电子邮件地址。
- 解释谁将接收/审查发送到该地址的邮件，以及关于将采取的任何自动操作的信息（例如，在 bug 跟踪器中提出机密问题）。
- 对于个人，与您的地址关联的可用于验证从您那里接收的电子邮件和根据需要加密发送给您的电子邮件的公钥的 ID。

提交后，您的请求将由 Django 开发团队考虑；您将在30天内收到回复，通知您请求的结果。

请您也要记住，对于任何个人或组织来说，接收安全通知是由 Django 开发团队完全自行决定的特权，而且这个特权可以在任何时候被撤销，有或无需解释。

> **提供所有必要的信息**
>
> 如果您在初始联系中未提供所需的信息，将影响我们是否批准您的请求的决定。