Django 1.1.4 发行说明 — Django 文档

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.4 是当前使用或针对 Django 1.1 的任何开发或部署的推荐升级。

有关 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 请求，从而破坏了信任 AJAX 请求同源性质的 CSRF 保护。

Rails 团队的 Michael Koziarski 引起了我们的注意，我们能够产生一个概念证明，证明 Django 的 CSRF 处理中存在相同的漏洞。

为了解决这个问题，Django 现在将对所有请求应用完整的 CSRF 验证，而不管明显的 AJAX 来源。 这在技术上是向后不兼容的，但在这种情况下，安全风险被判断为超过兼容性问题。

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

请参阅 CSRF 文档，例如演示此技术的 jQuery 代码 ，确保您正在查看您的 Django 版本的文档，因为某些旧版本的 Django 所需的确切代码是不同的。