CSRF Double Submit Cookie 基本上“不安全”

Question

来自OWASP 页面：CSRF 攻击有效，因为浏览器请求会自动包含所有 cookie，包括会话 cookie。

为了防止它，我们可以使用双重提交 cookie 哈希。
在我找到的一些示例代码中，基本上找到了这个算法。

受害者访问应用程序：

1. 后端：生成登录cookie和与登录cookie相关的哈希字符串
2. 前端：将哈希字符串存储到第二个 cookie 中（比如：CSRF-token cookie）
3. 前端（安全）：发送带有登录 cookie 和 CSRF HTTP 标头的请求，其中标头值是从 CSRF-token cookie 中提取的。

攻击者：

1. 使用某种社交媒体工程让用户点击恶意链接，这个恶意链接使用会话cookie。
2. 攻击者然后窃取此会话 cookie 以受害者身份登录

双重提交 cookie 应该可以防止这种攻击，因为攻击者还需要在 HTTP 标头中提供有效的 CSRF 令牌。

我还是不明白：如果浏览器请求自动包含所有 cookie，这意味着点击恶意链接，登录 cookie 和 CSRF-token cookie 也会包含在内，攻击者会窃取它们。
那么攻击者只需要从CSRF-token cookie中提取值，并创建自己的API访问，使用他窃取的登录cookie和提取值的CSRF HTTP标头？

我错过了什么吗？

谢谢

Answer 1

虽然 Gabor 基本上回答了这个问题，但我只是想强调一些重要的部分，因为我也曾经对这种双重提交 cookie 技术感到困惑。

这里的主要误解是假设发生 CSRF 攻击是因为攻击者能够从“targetweb.com”窃取 cookie，而实际上攻击者根本不需要知道 cookie 的值！

要发生CSRF攻击，攻击者只需要4个条件：

1. 目标站点上的会话已建立（用户已登录“targetweb.com”）
2. 攻击者知道某些操作的请求格式（例如转账）
3. 会话令牌存储在 cookie 中。
4. 用户在不知情的情况下触发某些东西（例如按钮/链接），向“targetweb.com”发送请求。

攻击者所需要做的就是让用户在用户不知情的情况下触发攻击者伪造的请求（重要的是，伪造的请求不需要包含会话 cookie，因为它将被添加稍后在发送时由浏览器自动发送 - 因此攻击者不需要它的值）。

现在，通过双重提交 cookie 技术，服务器在 cookie 中发送附加值。攻击者不知道其价值。当发出请求时，该值还需要附加到请求标头（不会自动添加）中。然后，服务器将此标头值与 cookie 值进行比较，仅当值匹配时才继续。

与攻击者的观点不同的是，现在他需要将值附加到标头中以使请求有效。而且他不知道这个值，因此防止了 CSRF。

Answer 2

一些事情似乎在这里混淆了。

因此，在原始同步器令牌模式中，您将生成一个随机令牌，将其存储在服务器端以供用户会话使用，并将其发送给客户端。然后客户端会将令牌作为表单值或请求标头发回，而不是作为 cookie，因此它不会自动发送 - 这就是重点。（服务器当然会将请求中的令牌与会话中的令牌进行比较。）

在双重发布中，令牌甚至不需要在服务器端生成，客户端也可以生成（或者服务器可以发送它，如果我们接受加密在 Javascript 中足够好就没有那么重要了）。

令牌将作为 cookie 发送，也将作为其他内容（表单值、请求标头、任何未自动发送的内容）发送。如果服务器将它作为 cookie 发送（显然没有 httpOnly），客户端可以从中读取它并将其作为非 cookie 也包含在请求中。服务器将再次比较两者。

关键是attacker.com 上的攻击者将无法访问应用程序域的cookie（既不能读取也不能写入）。因此，如果客户端可以读取 cookie 并将其作为其他内容包含在请求中，则该客户端必须在应用程序源上运行（如果我们仅讨论未修改的浏览器），则不会执行 CSRF。客户端也可以自己创建整个令牌，因为attacker.com 仍然无法为应用程序域创建cookie。

所以基于上述，如果一切都只是在cookies中，则实现是错误的，并且不能防止CSRF。