Django 1.1.4 版本发行说明

欢迎来到 Django 1.1.4 版本!

这是 Django 1.1 系列的第四个“错误修复”版本,改进了 Django 1.1 代码库的稳定性和性能。

除了一个例外,Django 1.1.4 与 Django 1.1.3 兼容。它还包含了一些修复和其他改进。对于当前使用或目标为 Django 1.1 的任何开发或部署,推荐升级到 Django 1.1.4 。

有关 1.1 分支中新功能、向后不兼容性和已弃用功能的详细信息,请参阅 Django 1.1 版本发行说明

不向后兼容的变更

AJAX 请求的 CSRF 例外

Django 包含一个 CSRF 保护机制,它通过在传出的表单中插入一个令牌来实现。然后,中间件在表单提交时检查令牌的存在,并对其进行验证。

在 Django 1.2.5 之前,我们的 CSRF 保护对 AJAX 请求做了一个例外,基于以下原因:

  • 许多 AJAX 工具包在使用 XMLHttpRequest 时会添加一个 X-Requested -With 头部。
  • 浏览器对于 XMLHttpRequest 具有严格的同源策略。
  • 在浏览器的上下文中,只有使用 XMLHttpRequest 才能添加这种自定义头部。

因此,为了方便使用,我们基于 X-Requested-With 头部,对看起来是 AJAX 请求的请求没有应用 CSRF 检查。 Ruby on Rails Web 框架也有类似的例外情况。

最近,Google 的工程师向 Ruby on Rails 开发团队的成员们提醒了一种结合浏览器插件和重定向的技术,可以允许攻击者在向任何网站发出请求时提供自定义的 HTTP 头信息。这可以使伪造的请求看起来像是 AJAX 请求,从而破坏了 CSRF 保护机制,因为它信任 AJAX 请求具有同源性质。

Rails 团队的 Michael Koziarski 向我们提出了这个问题,我们能够制作出一个概念验证,证明了 Django 的 CSRF 处理也存在同样的漏洞。

为了解决这个问题,Django 现在将对所有请求应用完整的 CSRF 验证,无论它们看起来是否来自 AJAX 。从技术上讲,这是不兼容的,但在这种情况下,安全风险被认为超过了兼容性问题。

此外,Django 现在将接受自定义 HTTP 头 X-CSRFTOKEN 中的 CSRF 令牌,以及表单提交本身中的令牌,以便与流行的 JavaScript 工具包一起使用,这些工具包允许在所有 AJAX 请求中插入自定义头。这样做是为了方便使用。

请参阅 CSRF 文档中的示例 jQuery 代码,该代码演示了这个技巧,确保您查看的是适用于您的 Django 版本的文档,因为一些较旧版本的 Django 需要不同的确切代码。