Django 1.4.18 发行说明 — Django 文档

Django 1.4.8 版本发行说明

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 的供应商 6 版本 django.utils.six 已降级到 1.8.0，这是支持 Python 2.5 的最后一个版本。