Django 1.8.10发行说明

2016年3月1日

Django1.8.10修复了1.8.9中的两个安全问题和几个错误。

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

Django在某些情况下依赖于用户输入（例如 django.contrib.auth.views.login() 和 i18n ）将用户重定向到“on success”URL。这些重定向的安全检查（即 django.utils.http.is_safe_url() ）在不应该的情况下，考虑了一些具有基本身份验证凭据“安全”的URL。

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

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

CVE-2016-2513：密码散列器工作因子升级计时差用户枚举

在Django自1.6以来的每个主要版本中， PBKDF2PasswordHasher 它的子类也增加了。随着硬件速度的提高，这提高了密码的安全性，但是，它还为密码编码在旧迭代次数中的用户的登录请求和不存在的用户的登录请求（运行自Django 1.6以来的默认哈希迭代次数）之间创建了时间差。

这只影响自迭代次数增加后未登录的用户。用户在迭代次数增加后首次登录时，其密码会随着新迭代次数更新，并且不再存在时间差异。

新的 BasePasswordHasher.harden_runtime() 方法允许散列程序在现有编码密码中提供的工作因子（例如迭代次数）和散列程序的默认工作因子之间建立运行时间隙。此方法用于 PBKDF2PasswordHasher 和 BCryptPasswordHasher . 自Django1.4以来，后一个散列的轮次没有改变，但是一些项目可能会将其子类化，并根据需要增加工作系数。

对于任何 third-party password hashers that don't implement 一 harden_runtime() 方法。

如果数据库中有不同的密码散列（例如，在Django 1.4中，自默认散列器切换到pbkdf2后未登录的用户的sha1散列），则这些用户登录请求的时间差可能会更大，而此修复程序无法弥补这一差异（或更改散列器时的任何差异）。你也许可以 upgrade those hashes 以防止针对该案例的定时攻击。

错误修正

  • 修复了PostgreSQL上阻止使用的崩溃 TIME_ZONE=None 和 USE_TZ=False (#26177 ）

  • 添加了对隐藏关系的查询名称冲突的系统检查 (#26162 ）

  • 制造 forms.FileField 和 utils.translation.lazy_number() 可腌制的 (#26212 ）

  • 固定的 RangeField 和 ArrayField 序列化方式 None 价值观 (#26215 ）

  • 在顶级域名中重新分配破折号 URLValidator 在Django 1.8中修复回归 (#26204 ）

  • 固定的 BoundField 重新分配子桥片 (#26267 ）

  • 预防的 ContentTypeManager 共享缓存的实例 (#26286 ）

« previous | up | next »