CVE-2016-2512：通过包含基本身份验证的由用户提供的重定向 URL 进行恶意重定向和可能的 XSS 攻击

Django 在某些情况下依赖用户输入（例如django.contrib.auth.views.login()和 i18n）将用户重定向到“成功后”的 URL。这些重定向的安全检查（即django.utils.http.is_safe_url()) 将某些包含基本身份验证凭据的 URL 视为“安全”，但实际上不应该。

例如，类似于http://mysite.example.com\@attacker.com的 URL 如果请求的主机是http://mysite.example.com，则会被视为安全，但重定向到此 URL 会将用户发送到attacker.com.

此外，如果开发人员依赖is_safe_url()提供安全的重定向目标并将此类 URL 放入链接中，他们可能会遭受 XSS 攻击。

感谢 Mark Striemer 报告此问题。

CVE-2016-2513：通过密码哈希器工作因子升级时的时差进行用户枚举

从 1.6 版开始，Django 的每个主要版本中，PBKDF2PasswordHasher及其子类的默认迭代次数都增加了。这提高了密码的安全性，因为硬件速度在不断提高，但是，它还在使用旧迭代次数编码的密码的用户登录请求和不存在的用户登录请求（由于 Django 1.6，运行默认哈希器的默认迭代次数）之间产生了时差。

这仅影响自迭代次数增加以来未登录的用户。用户在迭代次数增加后第一次登录时，其密码将使用新的迭代次数进行更新，并且不再存在时差。

新的BasePasswordHasher.harden_runtime()方法允许哈希器弥合现有编码密码中提供的因子（例如迭代次数）与哈希器的默认因子之间的运行时差距。此方法已为PBKDF2PasswordHasher和BCryptPasswordHasher实现。后者哈希器的轮数自 Django 1.4 以来没有改变，但某些项目可能会对其进行子类化并根据需要增加工作因子。

对于任何未实现harden_runtime()方法的第三方密码哈希器，都会发出警告。

如果您的数据库中包含不同的密码哈希（例如，自默认哈希器在 Django 1.4 中切换到 PBKDF2 以来未登录用户的 SHA1 哈希），则对这些用户的登录请求的时差可能更大，并且此修复程序无法解决该差异（或更改哈希器时的任何差异）。您可能能够升级这些哈希 以防止在这种情况下发生时序攻击。

感谢 Sjoerd Job Postmus 报告此问题。

受影响的支持版本

• Django 主开发分支
• Django 1.9
• Django 1.8

根据我们的支持版本策略，Django 1.7 及更旧版本不再接收安全更新。

解决方案

已将解决这些问题的补丁应用于 Django 的主开发分支和 1.9 和 1.8 发布分支。这些补丁可以从以下更改集中获取

在开发主分支上：* is_safe_url() 补丁 * 哈希器补丁

在 1.9 发布分支上：* is_safe_url() 补丁 * 哈希器补丁

在 1.8 发布分支上：* is_safe_url() 补丁 * 哈希器补丁

已发布以下新版本

• Django 1.9.3 (下载 Django 1.9.3 | 1.9.3 校验和)
• Django 1.8.10 (下载 Django 1.8.10 | 1.8.10 校验和)

这些版本使用的 PGP 密钥 ID 为 Tim Graham：1E8ABDC773EDE252。

关于安全报告的一般说明

与往常一样，我们请求您通过私人电子邮件将潜在的安全问题报告至security@djangoproject.com，而不是通过 Django 的 Trac 实例或 django-developers 列表。请参阅我们的安全策略以获取更多信息。