2016年3月1日
Django1.9.3修复了1.9.2中的两个安全问题和几个错误。
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攻击。
在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 以防止针对该案例的定时攻击。
跳过URL检查（在1.9中是新的），如果 ROOT_URLCONF 未定义设置 (#26155 ）
修复了PostgreSQL上阻止使用的崩溃 TIME_ZONE=None 和 USE_TZ=False (#26177 ）
添加了对隐藏关系的查询名称冲突的系统检查 (#26162 ）
修正了以下情况的回归 ForeignObject.get_extra_descriptor_filter() 返回A Q 对象 (#26153 ）
固定回归 __in=qs 查找一个 ForeignKey 具有 to_field 设置 (#26196 ）
制造 forms.FileField 和 utils.translation.lazy_number() 可腌制的 (#26212 ）
固定的 RangeField 和 ArrayField 序列化方式 None 价值观 (#26215 ）
修正了通过 Decimal 在里面 RawQuery (#26219 ）
在顶级域名中重新分配破折号 URLValidator 在Django 1.8中修复回归 (#26204 ）
固定了一些破碎脱粘垫片 SimpleTemplateResponse 在姜戈回归1.9 (#26253 ）
固定的 BoundField 重新分配子桥片 (#26267 ）
已更改登录模板中管理员的“权限被拒绝”消息以使用 get_username 而不是 username 支持自定义用户模型 (#26231 ）
修复了将不存在的模板名称传递到缓存的模板加载程序时的崩溃 load_template() 方法 (#26280 ）
预防的 ContentTypeManager 共享缓存的实例 (#26286 ）
恢复了Django 1.9.2中的更改 (#25858 ）这就阻止了抽象模型上定义的相对懒惰关系根据其具体模型进行解析。 app_label (#26186 ）
7月 22, 2024