security - 如何将CSRF token 从服务器传递到客户端？

Question

这听起来像是一个愚蠢的问题。我想弄清楚这一点。如果 token 首先发送到客户端并且客户端发回相同的 token ，那么 csrf token 如何帮助识别跨站点请求？恶意客户端不会从服务器获得响应。

如果我们在发送 token 的同时检查来源，那么 token 检查的事情是不是显得多余？

我们如何确保服务器只会将 token 提供给授权的客户端，以及将 token 从服务器传输到客户端的最佳实践是什么？

我曾问过一个相关问题 here但需要更深入地了解它。所以在这里问一个不同的问题。

希望通过例子得到一些答案。

先感谢您

Answer 1

CSRF 基本上是关于攻击者通过 cookie 在浏览器中的工作方式利用用户现有 session 。潜在的问题是，无论请求来自何处(哪个来源，即域)，cookie 都会随请求一起发送，唯一重要的是它去往何处。因此，如果有用户登录到应用程序(具有 session cookie)，攻击者可能会尝试让该用户访问他的恶意网站，从那里攻击者可以使用用户的凭据向应用程序域发出请求(通过完全将用户发布到应用程序，或更巧妙地通过创建 ajax 请求)。

请注意，这仅适用于应用程序中的身份验证基于浏览器自动发送的内容时，最明显的是 session cookie，但例如基本的 http 身份验证或客户端证书身份验证也可能容易受到攻击。此外，CSRF 仅适用于更改某些内容(状态或数据)的请求。

有一件重要的事情在起作用，同源策略 (SOP) 是浏览器。稍微简化一下，这意味着如果从一个域(或更准确地说:源)下载某些内容，则另一个域将无法访问。

因此，为了防止上述攻击并防止攻击者在自己的域上让用户向用户登录的应用程序发送不需要的请求，可能有几种不同的策略。

同步器 token

应用程序生成一个 csrf token ，将其存储在用户的 session (服务器端)中，并将其发送到客户端，例如将其写入隐藏字段中的每种形式，或写入 Javascript 可以从中读取它的单个字段中并添加到请求中。这是有效的，因为他域中的攻击者无法使用用户 session 中的有效 token 创建表单或请求，并且攻击者也无法从应用程序页面读取 token 。当然，攻击者可以尝试下载申请表以获取 token ，但随后他将需要凭据。攻击者需要有效的用户 session 和相应的 csrf token 。攻击者可能有自己的适当帐户来登录，但无论如何他都可以执行操作。或者他可能有一个 csrf token ，但要么未经身份验证，要么使用较低权限的帐户。但他不能两者兼得，这就是重点。

因此，这种保护基本上可以验证请求是否来自合法应用程序实际呈现的源，而不是其他人。

请注意，在这种情况下，在 cookie 中设置 token 是没有意义的，因为 cookie 会像 session cookie 一样自动发送。

双重发布

另一种策略是生成 token ，并将其设置为客户端的 cookie。然后客户端从 cookie 中读取 token ，并将相同的 token 作为请求头发送。服务器只比较请求头和cookie是否包含相同的token。这是有效的，因为攻击者无法从不同来源设置的 cookie 中读取应用程序 token (参见上面的 SOP)，但合法域上的应用程序可以。所以发送请求的客户端有效地证明它运行在合法的应用程序域上。这样做的好处是应用程序是无状态的，不需要 session 。缺点是它的安全性稍差。

(有趣的是，这种情况下的 token 甚至可以在客户端生成，它仍然有效，因为他自己域的攻击者无法设置或读取应用程序域的 cookie，但它绝对不那么安全，因为它是加密操作浏览器。)

检查引用者或来源

正如您正确指出的，另一种策略可能是检查请求的引用者或来源。它基本上有效，但被认为不太安全。虽然对于许多应用程序来说，双重发布被认为足够安全，但引用者/来源检查大多不是。我认为它具有很强的历史元素，但仍然不那么安全。

这个问题有很多方面，其中一些是浮现在脑海中的:

发送referer/origin header can be prevented攻击者在他自己的域上。所以应用程序不会知道它是一个不同的域——它只是没有信息。您当然可以以需要引用者和/或来源的方式实现它，但这会导致潜在的错误和浏览器由于某种原因不发送它的问题等。

在某些情况下，Referer 和 origin 可能是伪造的。例如，旧的易受攻击的浏览器插件(Java、Flash……还有人记得 Flash 吗？)允许设置任何 header ，攻击者只需要在受害浏览器中安装其中之一——每个人都有。

浏览器扩展还可以设置/修改 header ，因此攻击者可能会尝试让受害用户安装他的恶意扩展。

Origin 仅由现代浏览器设置。现在问题不大了，大多数人使用的浏览器都设置了引用者和来源。

因此，出于这些原因，简单地检查引用者/来源并不是很健壮，应该有另一层保护。

同站点 cookie

Google 在 Chrome 中的一项新发明是 SameSite cookie 的属性(除了已经存在且广泛使用的 httpOnly 和 secure cookie 属性)。截至目前，它仅受 Chrome 支持，其他浏览器不支持。

如上所述，潜在的问题是 cookie(即 session cookie)根据请求目标而不是源发送到服务器。这意味着，如果attacker.com 向用户提供一个页面，并且该页面从浏览器向legitapp.com 发送post 请求，则legitapp.com 设置的任何cookie 都将发送到legitapp.com。因此，如果是登录到legitapp.com 访问attacker.com 的用户，则可以利用现有 session 。

这是由 SameSite cookie attribute 改变的，这使得在原始域与目标域不同的情况下不会发送 cookie。它可以设置为 'strict' 或 'lax'，这基本上决定了 GET 请求的行为，但其中任何一个都会阻止 CSRF
非 GET 请求。