代码之家  ›  专栏  ›  技术社区  ›  pramesh

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

  •  8
  • pramesh  · 技术社区  · 7 年前

    如果我们在发送令牌时检查源代码,那么令牌检查的事情看起来不是多余的吗?

    我问了一个相关的问题 here

    希望得到一些例子的答案。

    1 回复  |  直到 5 年前
        1
  •  0
  •   Gabor Lengyel    7 年前

    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请求。