Question

给出以下一系列事件

匿名用户打开主页，该主页包含一个表单（带有有效的csrf令牌）
用户打开辅助选项卡并登录。
用户返回到原始标签并提交表单。

预期的结果是csrf故障吗？如果是，是否有任何解决方案可以使用户获得更好的体验？

Answer 1

是的，这是安全系统的一部分。鉴于攻击者可能会生成/获取属于匿名用户的CSRF令牌（因为它们也是匿名用户），因此在用户登录后使用该令牌绝对不是一个明智的主意。Django {{3 }}作为安全措施，并且他们有documents this behavior记录着relevant ticket的文件。

这也是为什么某些站点（例如github）会警告用户，如果在一个选项卡中完成了登录/注销操作，则需要在用户浏览器会话的所有其他选项卡上重新加载页面。没有安全的措施可以避免这种情况。

Answer 2

对于这个确切的问题，并且假设Django的CSRF_COOKIE_HTTPONLY的默认值为False，则此onfocus处理程序似乎可以正常工作：

$(document).ready(function () {
    $(window).on('focus', function () {

         var cookie_csrf = dk.web.cookie.get('csrftoken');  // or Cookie.get(..) or something similar
         var dom_csrf = $('[name=csrfmiddlewaretoken]:first');

         if (cookie_csrf !== dom_csrf) {
             // other tab has caused the csrf cookie to change
             $('[name=csrfmiddlewaretoken]').each(function () {
                 $(this).val(cookie_csrf);
             });
         }
    });
});

似乎有点骇人听闻，所以刷新页面可能“更好”：

if (cookie_csrf !== dom_csrf) {
    window.location.reload(true);  // reload the current page, without using the cache
}

刷新页面将获得登录后对页面的任何更改，但会删除用户输入的所有输入。

假设您没有XSS漏洞（通常在涉及csrf时假定），从.js访问csrf令牌是安全的。

这项技术基于这样一个事实，即cookie和dom中的csrf令牌的值是相同的，这在设计上就与Django相同。

是否会出现此csrf故障？

2 个答案: