我正在尝试找到以下问题的答案。
- 在什么情况下,浏览器会存储多个
csrftoken
cookie? - 这是否是正确的、技术上有效的功能?
- 在RFC/安全文档中,传递一个数组或尝试使用
csrftoken
数组在哪里存在或者是技术上有效的?
我附上了一个示例截图,显示了多个具有不同cookie路径和过期时间(多租户和各种表单路径)的csrftoken
。
相关链接:
我正在尝试找到以下问题的答案。
csrftoken
cookie?csrftoken
数组在哪里存在或者是技术上有效的?我附上了一个示例截图,显示了多个具有不同cookie路径和过期时间(多租户和各种表单路径)的csrftoken
。
相关链接:
/
上更新/刷新CSRF令牌cookie。这真的取决于您的服务器如何解释跟随每个令牌请求的潜在表单提交。一种简单的方法是在设置cookie之前将新生成的令牌存储在用户的会话存储(内存或数据库)中。然后,在用户的表单POST到达时,在服务器上再次比较这两个令牌。
csrftoken
,它们也具有相同的域 - 127.0.0.1
,但路径对于每个cookie是唯一的。因此,不同的范围(更具体地说,路径)允许拥有多个cookie。
描述CSRF攻击保护措施最常被引用和尊重的文件是OWASP跨站请求伪造防范备忘单(GitHub Markdown变体)。
会话更改视图(登录/注销/密码更改)以及其他重要和高安全性视图(例如资金转移)可以和应该使用高级和/或其他技术进行保护(例如用户交互)。
/graphql
端点发出请求,该端点依次遍历所有其他rest api端点,好像将来可能会对它们进行POST/PUT/PATCH
请求,每个端点/视图都向响应中添加自己的per-path/per-form
(甚至是每个请求)csrftoken cookie。此外,看起来采用这种方法,下一个请求不是预期发送到/graphql
端点,而是直接发送到其中一个rest api端点/视图url。/graphql
端点,所有请求都将发送到该端点。如果您想为Django添加Graphql API
,请查看Graphene。
如果您想使用单独的前端应用程序与Django后端一起使用,那么您一定要查看django-cors-headers(并使用它)。