如何将CSRF令牌从服务器传递到客户端?

CSRF基本上是指攻击者通过浏览器中cookie的工作方式,利用用户的现有会话。根本的问题是,无论请求来自哪里(哪个来源,即域),cookie都会随请求一起发送 ,唯一重要的是它去了哪里 到

同步器令牌

因此,这种保护基本上验证了请求是否来自合法应用程序实际提供的源,而不是其他人。

双重邮寄

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

检查推荐人或来源

正如您正确指出的,另一种策略可能是检查请求的引用者或来源。它基本上可以工作,但被认为不太安全。虽然对于许多应用程序来说,双重发布被认为是足够安全的,但推荐人/来源检查基本上是不安全的。我认为这其中有很强的历史因素,但仍然是真的 是

这个问题有很多方面,其中一些是我想到的:

• 发送referer/origin标题 can be prevented
• 浏览器扩展还可以设置/修改标题,因此攻击者可能会试图让受害者用户安装其恶意扩展。
• “起源”仅由现代浏览器设置。现在问题不那么严重了,大多数人使用的浏览器同时设置了referer和origin。

因此,出于这些原因,简单地检查referer/origin并不是很可靠,应该有另一层保护。

SameSite httpOnly secure cookie属性)。到目前为止,它只受Chrome浏览器支持,其他浏览器不支持。

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