Django 1.7.3 版本发行说明

2015 年 1 月 13 日

Django 1.7.3 修复了 1.7.2 版本中的一些安全问题和错误。

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

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

不幸的是,这意味着 WSGI 环境无法区分包含破折号和包含下划线的头部:X-Auth-UserX-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 服务器提供文件。

使用 ModelMultipleChoiceField 存在数据库拒绝服务漏洞

针对使用 ModelMultipleChoiceField 并且使用 show_hidden_initial=True 的表单(这不是文档化的 API)可能会导致用户通过提交字段数据的重复值来引发不合理数量的 SQL 查询。ModelMultipleChoiceField 中的验证逻辑现在会去重提交的值,以解决这个问题。

漏洞修复

  • PBKDF2 密码哈希器的默认迭代次数增加了 25%。这是正常的主要发布流程的一部分,在 1.7 版中无意中被遗漏。这个向后兼容的更改不会影响那些已经子类化了 django.contrib.auth.hashers.PBKDF2PasswordHasher 以更改默认值的用户。
  • 修复了 CSRF 中间件在处理非 ASCII referer 头部时的崩溃问题(#23815)。
  • 修复了在 Python 3 上传递 reverse_lazy() 结果时,django.contrib.auth.redirect_to_login 视图中的崩溃问题(#24097)。
  • 为希腊语(el)添加了正确的格式(#23967)。
  • 修复了在取消应用多个操作与同一模型交互的迁移时出现的崩溃问题(#24110)。
Back to Top