如何将CSRF令牌从服务器传递到客户端? [英] How to pass CSRF token from server to client?

查看:19
本文介绍了如何将CSRF令牌从服务器传递到客户端?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这听起来可能是个愚蠢的问题。我想把这件事说清楚。如果令牌首先发送到客户端,而客户端发回相同的令牌,CSRF令牌如何帮助识别跨站点请求?恶意客户端不会从服务器获得响应吗?

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

如何确保服务器只向授权的客户端提供令牌?将令牌从服务器传输到客户端的最佳做法是什么?

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

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

提前谢谢您

推荐答案

CSRF基本上是关于攻击者通过Cookie在浏览器中的工作方式利用用户的现有会话。潜在的问题是,Cookie与请求一起发送,而不管它来自哪里(即。域)请求来自,唯一重要的是它到达的位置。因此,如果有用户登录到应用程序(具有会话Cookie),攻击者可能会尝试让该用户访问他的恶意网站,在那里攻击者可以使用用户的凭据向应用程序域发出请求(通过将用户完全发送到应用程序,或者更巧妙地通过创建AJAX请求)。

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

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

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

同步器令牌

应用程序生成一个CSRF令牌,将其存储在用户的会话(服务器端)中,并将其发送到客户端,例如,将其以各种形式写入隐藏字段中,或写入一个单独的字段中,在该字段中,Java脚本可以读取该令牌并将其添加到请求中。这是可行的,因为其域上的攻击者无法使用用户会话中的有效令牌创建表单或请求,并且攻击者也无法从应用程序页面读取令牌。当然,攻击者可以尝试下载应用程序表单来获取令牌,但随后他将需要凭据。攻击者需要有效的用户会话和相应的CSRF令牌。攻击者可能有自己的相应帐户来登录,但无论如何他都可以只执行该操作。或者,他可能有一个CSRF令牌,但未经过身份验证,或者连接到较低权限的帐户。但他不能两者兼得,这就是问题所在。

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

请注意,在这种情况下,在Cookie中设置令牌是没有意义的,因为Cookie将像会话Cookie一样自动发送。

双重发布

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

(有趣的是,本例中的令牌甚至可以在客户端生成,但它仍然有效,因为他自己域上的攻击者无法设置或读取应用程序域Cookie,但它的安全性肯定较低,因为它是浏览器中的加密操作。)

检查推荐人或来源

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

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

  • 攻击者在自己的域上发送Referer/Origin报头can be prevented。因此,应用程序不会知道它是一个不同的域-它只是没有信息。当然,您可以通过需要引用和/或来源的方式来实现它,但这会导致潜在的错误和问题,浏览器出于某种原因不会发送它。
  • 在某些情况下,引用人和来源可能是伪造的。例如,旧的易受攻击的浏览器插件(Java、Flash...还有人记得Flash吗?)允许设置任何标头,攻击者只需要在受害者浏览器中安装其中一个标头-每个人都有它们。
  • 浏览器扩展还可以设置/修改标头,因此攻击者可能会尝试由受害用户安装其恶意扩展。
  • Origin仅由现代浏览器设置。现在问题不大了,大多数人使用同时设置引用人和来源的浏览器。

因此,出于这些原因,简单地检查引用人/来源并不是很可靠,应该另外建立一层保护。

SameSite Cookie

Google在Chrome中的一项新发明是Cookie的SameSite属性(除了已经存在且广泛使用的httpOnlysecureCookie属性)。到目前为止,只有Chrome支持它,其他浏览器不支持。

如上所述,根本问题是Cookie(即.会话Cookie)基于请求目标而不是源被发送到服务器。这意味着,如果attacker.com向用户提供一个页面,并且该页面从浏览器向Legitapp.com发送POST请求,则由Legitapp.com设置的任何Cookie都将发送到Legitapp.com。因此,如果是登录到Legitapp.com访问attacker.com的用户,则可以利用现有会话。

SameSite cookie attribute会改变这一点,这使得在源域与目标域不同的情况下不会发送Cookie。它可以设置为"严格"或"宽松",这基本上决定了GET请求的行为,但使用其中的任何一个都会阻止CSRF打开 非GET请求。

这篇关于如何将CSRF令牌从服务器传递到客户端?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆