Django 1.4.18 版本发行说明

2015 年 1 月 13 日

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

通过下划线/破折号混淆进行 WSGI 头欺骗

当将 HTTP 头放入 WSGI 环境时，它们会被规范化，即转换为大写，将所有破折号转换为下划线，并在前面添加 HTTP_。例如，一个名为 X-Auth-User 的头部在 WSGI 环境中会变成 HTTP_X_AUTH_USER （因此也会出现在 Django 的 request.META 字典中）。

不幸的是，这意味着 WSGI 环境无法区分包含破折号和包含下划线的头部：X-Auth-User 和 X-Auth_User 都会变成 HTTP_X_AUTH_USER。这意味着如果一个头部以安全敏感的方式使用（例如，从前端代理传递身份验证信息），即使代理仔细删除了 X-Auth-User 的任何传入值，攻击者仍然可以提供一个带下划线的 X-Auth_User 头部，并绕过这种保护。

为了防止此类攻击，Nginx 和 Apache 2.4+ 默认会从传入的请求中剥离包含下划线的所有标头。 Django 的内置开发服务器现在也采用相同的做法。不建议将 Django 的开发服务器用于生产环境，但匹配常见生产服务器的行为可以减少部署过程中行为变化的可能性。

通过用户提供的重定向 URL 减轻了可能的 XSS 攻击风险。

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

对 django.views.static.serve 的拒绝服务攻击

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

然而，请注意，这个视图一直带有一个警告，即它没有经过生产环境的强化，只应作为开发辅助工具使用。如果您还没有这样做，现在可能是一个好时机来审计您的项目，并在生产环境中使用真正的前端 Web 服务器提供文件。

漏洞修复

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