CSRFDoubleSubmitCookie基本上“不安全”
来自OWASP 页面：CSRF 攻击有效，因为浏览器请求会自动包含所有 cookie，包括会话 cookie。
为了防止它，我们可以使用双重提交 cookie 哈希。
在我找到的一些示例代码中，基本上找到了这个算法。
受害者访问应用程序：
- 后端：生成登录cookie和与登录cookie相关的哈希字符串
- 前端：将哈希字符串存储到第二个 cookie 中（比如：CSRF-token cookie）
- 前端（安全）：发送带有登录 cookie 和 CSRF HTTP 标头的请求，其中标头值是从 CSRF-token cookie 中提取的。
攻击者：
- 使用某种社交媒体工程让用户点击恶意链接，这个恶意链接使用会话cookie。
- 攻击者然后窃取此会话 cookie 以受害者身份登录
双重提交 cookie 应该可以防止这种攻击，因为攻击者还需要在 HTTP 标头中提供有效的 CSRF 令牌。
我还是不明白：如果浏览器请求自动包含所有 cookie，这意味着点击恶意链接，登录 cookie 和 CSRF-token cookie 也会包含在内，攻击者会窃取它们。
那么攻击者只需要从CSRF-token cookie中提取值，并创建自己的API访问，使用他窃取的登录cookie和提取值的CSRF HTTP标头？
我错过了什么吗？
谢谢
回答
一些事情似乎在这里混淆了。
因此，在原始同步器令牌模式中，您将生成一个随机令牌，将其存储在服务器端以供用户会话使用，并将其发送给客户端。然后客户端会将令牌作为表单值或请求标头发回，而不是作为 cookie，因此它不会自动发送 - 这就是重点。（服务器当然会将请求中的令牌与会话中的令牌进行比较。）
在双重发布中，令牌甚至不需要在服务器端生成，客户端也可以生成（或者服务器可以发送它，如果我们接受加密在 Javascript 中足够好就没有那么重要了）。
令牌将作为 cookie 发送，也将作为其他内容（表单值、请求标头、任何未自动发送的内容）发送。如果服务器将它作为 cookie 发送（显然没有 httpOnly），客户端可以从中读取它并将其作为非 cookie 也包含在请求中。服务器将再次比较两者。
关键是attacker.com 上的攻击者将无法访问应用程序域的cookie（既不能读取也不能写入）。因此，如果客户端可以读取 cookie 并将其作为其他内容包含在请求中，则该客户端必须在应用程序源上运行（如果我们仅讨论未修改的浏览器），则不会执行 CSRF。客户端也可以自己创建整个令牌，因为attacker.com 仍然无法为应用程序域创建cookie。
所以基于上述，如果一切都只是在cookies中，则实现是错误的，并且不能防止CSRF。