Django 1.7.3 release notes

2015年1月13日

Django 1.7.3修复了几个安全问题和错误在1.7.2。

WSGI header spoofing via underscore/dash conflation

当HTTP标头放置在WSGI环境中时，它们通过转换为大写，将所有破折号转换为下划线和前缀HTTP _进行规范化。例如，头部X-Auth-User在WSGI环境中（因此也在Django的request.META字典中）将变为HTTP_X_AUTH_USER。

不幸的是，这意味着WSGI环境不能区分包含破折号的标头和包含下划线的标头：X-Auth-User和X-Auth_User都变为HTTP_X_AUTH_USERThis means that if a header is used in a security-sensitive way (for instance, passing authentication information along from a front-end proxy), even if the proxy carefully strips any incoming value for X-Auth-User, an attacker may be able to provide an X-Auth_User header (with underscore) and bypass this protection.

为了防止这种攻击，Nginx和Apache 2.4+都默认剥离所有包含来自传入请求的下划线的头。Django的内置开发服务器现在也做同样的事情。不推荐将Django的开发服务器用于生产使用，但是匹配常用生产服务器的行为会减少部署期间行为更改的表面积。

Mitigated possible XSS attack via user-supplied redirect URLs

Django在一些情况下依赖于用户输入（例如，django.contrib.auth.views.login()和i18n）将用户重定向到“成功”网址。这些重定向（即django.utils.http.is_safe_url()）的安全检查未删除测试网址上的前导空白，因此考虑的网址如\njavascript:...安全。如果开发人员依赖is_safe_url()提供安全的重定向目标，并将这样的URL放入链接，他们可能遭受XSS攻击。这个bug目前不影响Django，因为我们只把这个URL放在Location响应头中，浏览器似乎忽略了JavaScript。

Denial-of-service attack against django.views.static.serve

在旧版本的Django中，django.views.static.serve()视图会读取它一次为一行提供的文件。因此，没有换行符的大文件将导致内存使用量等于该文件的大小。攻击者可以利用此漏洞并通过同时请求许多大文件来启动拒绝服务攻击。此视图现在读取块中的文件，以防止大量内存使用。

但是，请注意，此视图始终显示警告，它不会为生产使用而硬化，并且应仅用作开发辅助。现在可能是一个很好的时间来审核您的项目，并在生产中使用真正的前端Web服务器，如果你不这样做的文件。

Database denial-of-service with ModelMultipleChoiceField

给定一个使用ModelMultipleChoiceField和show_hidden_initial=True（不是记录的API）的表单，用户可能通过提交重复值来导致不合理的SQL查询数字段的数据。ModelMultipleChoiceField中的验证逻辑现在会对提交的值进行重复数据删除，以解决此问题。

Bugfixes

  • PBKDF2密码hasher的默认迭代计数已增加了25％。这部分正常的主要释放过程在1.7中被无意地省略了。此向后兼容的更改不会影响已对django.contrib.auth.hashers.PBKDF2PasswordHasher子类化的用户更改默认值。
  • 修复了处理非ASCII引用头（＃23815）时CSRF中间件崩溃。
  • 修复了在Python 3（＃24097）上传递reverse_lazy()结果时，django.contrib.auth.redirect_to_login视图中的崩溃问题。
  • 为希腊语（el）（＃23967）添加了正确格式。
  • 修复了在多个操作与同一模型（＃24110）进行交互时取消应用迁移时的迁移崩溃。