多个csrftoken cookie,RFC要求只有一个csrftoken吗?

6

我正在尝试找到以下问题的答案。

  • 在什么情况下,浏览器会存储多个 csrftoken cookie?
  • 这是否是正确的、技术上有效的功能?
  • 在RFC/安全文档中,传递一个数组或尝试使用csrftoken 数组在哪里存在或者是技术上有效的?

我附上了一个示例截图,显示了多个具有不同cookie路径和过期时间(多租户和各种表单路径)的csrftoken

enter image description here

相关链接:


你能展示一下如何为POST请求设置所需的令牌参数吗?你的截图有点让人困惑,我似乎无法理解截图右侧的内容,其中你展示了不同路径的csrftoken和“LastAccessed”。 - Nagaraj Tantri
2个回答

1
不一定要只有一个令牌,但更常见的方法是在单个根路径/上更新/刷新CSRF令牌cookie。这真的取决于您的服务器如何解释跟随每个令牌请求的潜在表单提交。一种简单的方法是在设置cookie之前将新生成的令牌存储在用户的会话存储(内存或数据库)中。然后,在用户的表单POST到达时,在服务器上再次比较这两个令牌。
  1. 当每个HTTP GET请求(响应令牌)指定自定义cookie路径时,浏览器会存储多个令牌cookie。更常见的方法是使用一个cookie来防止CSRF。
  2. 您可以使令牌特定于路径,但这并不会使您的令牌更安全。
  3. 测试令牌的有效性完全取决于您。
希望这有所帮助。

1
这里的令牌存储在cookies中。 Cookies 是根据其范围域名路径)以及cookie名称来确定唯一性。
在这种情况下,所有cookie具有相同的名称 - csrftoken,它们也具有相同的域 - 127.0.0.1,但路径对于每个cookie是唯一的。因此,不同的范围(更具体地说,路径)允许拥有多个cookie。

描述CSRF攻击保护措施最常被引用和尊重的文件是OWASP跨站请求伪造防范备忘单GitHub Markdown变体)。


生成一个csrf令牌并将其存储在cookie中,每个用户会话只有一个,这是最流行的方法。与会话相关联使其在cookie更改时受到一定保护。请注意,您应该使用其他方法(例如双重提交cookie并在请求正文中包含令牌)进行保护,因为cookie会自动发送请求。

会话更改视图(登录/注销/密码更改)以及其他重要和高安全性视图(例如资金转移)可以和应该使用高级和/或其他技术进行保护(例如用户交互)。


为什么会返回多个csrf令牌?
后端行为的可能解释是:这可能是尝试向应用程序添加graphql支持的一种方式。它看起来像是graphql与rest的结合。
/graphql端点发出请求,该端点依次遍历所有其他rest api端点,好像将来可能会对它们进行POST/PUT/PATCH请求,每个端点/视图都向响应中添加自己的per-path/per-form(甚至是每个请求)csrftoken cookie。此外,看起来采用这种方法,下一个请求不是预期发送到/graphql端点,而是直接发送到其中一个rest api端点/视图url。
使用Graphql,您只需要一个/graphql端点,所有请求都将发送到该端点。
同时,有多个csrf令牌(每个端点一个)并没有太多优势

如果您想为Django添加Graphql API,请查看Graphene

如果您想使用单独的前端应用程序与Django后端一起使用,那么您一定要查看django-cors-headers(并使用它)。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接