Django CSRF Cookie-为什么它在浏览器关闭时不过期？ [英] Django CSRF Cookie -- why doesn't it expire at browser close?
问题描述
Django允许您指定会话在浏览器关闭时到期（Chrome有所警告）。为什么不对CSRF cookie这样做？
Django allows you to specify that the session expires at browser close (with some caveats for Chrome). Why doesn't it do that for the CSRF cookie?
我问，因为在我看来CSRF令牌很容易被泄漏（例如，错误地放置了它）在发布到外部网站上），这将是一个缓解措施。我误会了什么吗？
I ask because it seems to me that the CSRF token is vulnerable to being leaked (e.g., by mistakenly putting it in a post to an external site), and this would be a mitigation for that. Am I misunderstanding something?
推荐答案
我将从卡尔链接的开发人员列表中重新发布我的答案，以便stackoverflow拥有它：
I'll repost my answer from the developer's list that Carl linked, so that stackoverflow has it too:
如果Cookie设置为在浏览器关闭时到期，则对于关闭浏览器的用户，这会导致CSRF
错误（或将上面带有
表单的页面加为书签），然后从浏览器缓存中加载该页面，然后
提交该表单。我对此用例是否值得支持
（例如，在移动设备上可能很重要），
存有矛盾，但我不认为将Cookie设置为在浏览器关闭$ b时到期$ b为原本正确配置的
站点（HTTPS，HSTS等）提供了很多安全优势。
If the cookie were set to expire at browser close, it would cause CSRF errors for users who closed a browser (or bookmarked a page with a form on it) and then loaded that page from a browser cache and submitted the form. I'm ambivalent about whether this use case is worth supporting (it may be important on mobile devices, for example), but I don't believe that setting the cookie to expire on browser close provides much security benefit to an otherwise properly configured site (HTTPS, HSTS, etc.).
Django的CSRF实现不同于其他许多将
CSRF信息与会话信息存储在服务器上的实现。 CSRF
机制的功能是将表单中提供的令牌与浏览器中作为cookie提供的
令牌进行匹配。如果您将Cookie设置为
zzz，它仍然可以正常运行。安全性来自
，这是攻击者无法设置cookie的事实，而不是它发生
包含任何特定的加密值。
Django's CSRF implementation differs[1] from many others which store CSRF information alongside session information on the server. The CSRF mechanism functions by matching a token provided in a form with a token provided as a cookie in the browser. If you set the cookie to 'zzz', it will still function perfectly well. The security comes from the fact that an attacker cannot set the cookie, not that it happens to contain any specific cryptographic value.
如果担心的是攻击者可以在会话之间访问用户的物理
计算机并窃取CSRF令牌，则将其设置为在浏览器中过期
关闭不会阻止攻击者插入已知值的cookie
，该值将在下一个会话期间使用。我不是
确信我们可以保护攻击者实际访问过
计算机的用户的令牌。
If the concern is that an attacker could access a user's physical computer between sessions and steal a CSRF token, setting it to expire at browser close would not prevent an attacker from inserting a cookie of known value that would be used during the next session. I'm not convinced we can secure the tokens of a user whose computer has been physically accessed by an attacker.
不过，如果可以令人信服地表明，将Cookie
设置为在浏览器关闭时到期不会破坏现有用例（移动
浏览器是我的主要关注）我愿意改变默认的
行为。如果任何非恶意用户
可以通过无辜行为触发CSRF警告，则通常将其视为错误。
Still, if it can be convincingly demonstrated that setting the cookie to expire at browser close would not break existing use cases (mobile browsers are my chief concern) I'd be open to changing the default behavior. We generally consider it a bug if any non-malicious user can, through innocent behavior, trigger the CSRF warning.
[1] Django的CSRF实现通常会在大多数笔测试器工具中引发各种错误的
警报，因为它不能精确地运行
与其他实现方式相同，并且不与会话
cookie绑定。
[1] Django's CSRF implementation usually sets off all kinds of false alarms in most pen-tester tools, since it doesn't work exactly the same way other implementations do, and isn't tied to the session cookie.
这篇关于Django CSRF Cookie-为什么它在浏览器关闭时不过期？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
