欢迎来到Django 1.1.4！
这是Django1.1系列中的第四个“错误修复”版本，提高了Django1.1代码库的稳定性和性能。
除了一个例外，django 1.1.4与django 1.1.3保持向后兼容性。它还包含许多修复和其他改进。django 1.1.4是当前使用或针对django 1.1的任何开发或部署的建议升级。
有关1.1分支中新功能、向后不兼容和不推荐使用的功能的完整详细信息，请参见 Django 1.1发行说明 .
Django包括一个CSRF保护机制，利用插入到输出表单中的令牌。然后中间件在表单提交时检查令牌是否存在，并对其进行验证。
在Django 1.2.5之前，我们的CSRF保护在以下基础上对Ajax请求进行了例外处理：
许多Ajax工具包在使用xmlhttpRequest时添加了一个x-requested-with头。
浏览器对xmlhttpRequest有严格的相同来源策略。
在浏览器上下文中，可以添加这种性质的自定义头的唯一方法是使用xmlhttpRequest。
因此，为了便于使用，我们没有对基于x-requested-with头的看起来是Ajax的请求应用CSRF检查。RubyonRailsWeb框架也有类似的例外。
最近，谷歌的工程师让RubyonRails开发团队的成员意识到浏览器插件和重定向的结合，这使得攻击者能够在任何网站的请求中提供自定义HTTP头。这可以使伪造的请求看起来像是Ajax请求，从而破坏信任Ajax请求相同来源性质的CSRF保护。
Rails团队的Michael Koziarski让我们注意到了这一点，并且我们能够提供一个概念证明，证明Django的CSRF处理中同样存在漏洞。
为了解决这个问题，Django现在将对所有请求应用完整的CSRF验证，而不考虑明显的Ajax来源。这在技术上是向后不兼容的，但是在这种情况下，安全风险已经被判断为大于兼容性问题。
此外，Django现在将接受自定义HTTP头x-csrf token以及表单提交本身中的csrf令牌，以便与流行的javascript工具包一起使用，后者允许将自定义头插入所有Ajax请求中。
请看 CSRF docs for example jQuery code 这演示了这种技术，确保您正在查看Django版本的文档，因为某些旧版本的Django所需的确切代码是不同的。
12月 18, 2023