是否设置 cookie 'SameSite=none; 安全'并提供 CSRF-TOKEN 是否足以防止可嵌入 Web 应用程序中的 CSRF？

Question

我的 Web 应用程序（进一步是 myApp）嵌入在单个第三方网页的 iframe 中。MyApp 设置 cookieSet-Cookie: JSESSIONID=38FE580EE7D8CACA581532DD37A19182; Path=/myapi; Secure; HttpOnly以维护用户会话。前一段时间它停止在 Chrome 中工作，因为https://blog.chromium.org/2020/02/samesite-cookie-changes-in-february.html更新更改了处理没有SameSite属性的cookie 的默认行为from Noneto Lax。

1. 我将从 myApp 主机发送 cookie 与SameSite=None; Secure. X-CSRF-TOKEN每个响应中还包含标头。myApp javascript 获取X-CSRF-TOKEN并将其放入对 myApp 主机的每个 XHR 请求的标头中。这足以防止CSRF攻击吗？

2. 是否应该Access-Control-Allow-Origin: third-party-webpage在响应中添加标头？

Answer 1

我做了更多研究，并认为我应该在这里发布我的结论。我误解了防伪中间件的工作原理。配置的cookieAddAntiforgery实际上并没有将token传输给客户端。相反，它似乎是加密或散列的令牌，用于验证必须在标头中提供的令牌。这允许无状态地完成令牌验证，因为浏览器将通过每个请求传回此 cookie 的值。我将此 cookie 称为下面的“验证 cookie”。

中间件不会自动将令牌本身传输给客户端。GetAndStoreTokens这必须通过调用并向客户端提供RequestToken值来设置为后续请求的标头来完成。在我们的应用程序中，我们使用单独的 cookie 来实现这一点（下面我将其称为“令牌 cookie”）。 这是演示此技术的 Microsoft 文章。

SameSite=None我已确定用于验证 cookie 和令牌 cookie是安全的。该SameSite设置对谁可以读取 cookie 值没有任何影响，它只是确定 cookie 是否会在将来的请求中发送到服务器。验证 cookie 必须与未来的请求一起发送回服务器，以便可以验证标头中提供的令牌。即使对于跨源请求，发送此 cookie 也是可以接受的，因为这些请求仅验证标头中是否提供了令牌。

使用令牌 cookie 也是可以接受的，SameSite=None因为我们仅使用此 cookie 向客户端提供值。在验证令牌时，我们从不从服务器上的 cookie 中读取该值，中间件从 header 中读取令牌。无论属性如何，不同来源都无法读取令牌 cookie 的值，SameSite因此保持安全。

我还意识到，防伪中间件早SameSite=Lax在 2020 年成为 chrome cookie 的默认值之前就采用了这种确切的模式。在此之前，验证 cookie 的默认行为始终是None. 因此，我认为可以合理地得出这样的结论：该技术现在与成为默认技术SameSite=None之前一样安全。Lax

注意：某些浏览器似乎无法SameSite=None正确处理 ，因此当应用程序托管在 iframe 中时，这些浏览器的防伪过程可能会失败。