Django 1.4.18 release notes

2015年1月13日

Django 1.4.18修复了1.4.17中的几个安全问题，以及1.4.17版本中对Python 2.5的回归。

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服务器，如果你不这样做的文件。

Bugfixes

  • 为了保持与Python 2.5的兼容性，Django的六个版本的django.utils.six已降级到1.8.0，这是支持Python 2.5的最后一个版本。