# Django 5.2.8 documentation

# 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 的版本。