由于 CSRF 故障（Django 1.2.3）导致间歇性 403

Posted 2023-03-31

【中文标题】由于 CSRF 故障（Django 1.2.3）导致间歇性 403

【英文标题】：Intermittent 403s due to CSRF failure (Django 1.2.3)

【发布时间】：2011-04-30 11:11:45

【问题描述】：

我有一个网站和 CSRF 有点疯狂/令人愤怒的错误。

我们在 Ubuntu 上使用 Apache2 + mod_wsgi 运行 Django 1.2.3、Python 2.6，并且已经让最终用户报告 403 CRSF 验证失败和 403 的结果。

我们所有的表格都有一个csrf_token 并且 - 据我所知 - 在本地开发和舞台上一切正常（我们还没有投入生产）......除了一个办公室（客户的，纳奇）。在随机情况下，他们会得到这样的 403，但随后刷新它就会消失（所以这不是 html 缺少令牌等）

我正在考虑原因和解决方案，可能是该办公室的代理缓存过于急切或设置不当，或类似情况，希望能在 Django/ Apache 处理***代理的方式（客户办公室可能不会更改其设置）或其他可能导致这些 CSRF 失败的原因。

顺便说一句：这是一个从头开始的 1.2.3 项目，而不是某种 1.1 升级，我们只使用单个标准/正确的 1.2.3 CSRFMiddleware 并手动添加 csrf_tokens - 而不是 CSRFResponseMiddleware 以自动包含 csrf_token

另外：这发生在两个单独的服务器（开发服务器和临时服务器）上，它们托管在不同的位置。共同因素是（理论上）相同的 Django/Apache/mod_wsgi 设置、相同的代码库和相同的办公室获得 403（并且无法在我们自己的位置复制 403）。

【参考方案1】：

只是一个更新，以防它帮助任何人。

我们放弃了 CRSF 保护以进行测试（通过使用 http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/）。这清除了 403s，但是对于来自同一个客户端/本地网络的零长度 POST 数据，我们有间歇性的 500s，这解释了 CSRF 失败是因为令牌存在于会话中但不存在于有效负载中（而不是其他方式）。

所以，具体来说，这不是 CSRF 问题，而是 POST-payload-getting-zapped-somewhere 问题。 （很可能是由于仅在一个位置配置错误的代理）

HTH

史蒂夫