了解什么是CSRF攻击以及如何锁定CSRF漏洞。
网络漏洞猖獗,而且越来越多。维护用户的安全和隐私比以往任何时候都更加重要。不解决网络漏洞,你的名声就毁了,你还会被监管机构罚款。你也会失去用户的信任。
web应用程序容易受到恶意软件、垃圾邮件和其他攻击——本文主要关注攻击媒介之一——跨站点请求伪造(CSRF)攻击。CSRF攻击尤其令人不安,因为它们可能在用户不知情的情况下发生。开发者或网站所有者也很难找到它们,因为恶意请求看起来与真实请求高度相似。
本文探讨了CSRF攻击,它是如何工作的,以及您可以采取什么步骤来准备它。
什么是CSRF攻击?
CSRF袭击是如何进行的?
获取请求的CSRF
员额请求的CSRF
减轻CSRF攻击的3种方法
如何使用CSRF令牌防止CSRF攻击
如何使用Referrer头防止CSRF攻击
什么是CSRF攻击?
跨站请求伪造攻击,也称为CSRF攻击,通过提交恶意请求,在不知不觉中欺骗认证用户执行意外操作。
CSRF袭击是如何运作的。(来源:Okta)
通常,CSRF攻击涉及改变状态的请求,因为攻击者没有收到响应。此类请求的示例包括删除记录、更改密码、购买产品或发送消息。所有这些都可能在用户不知情的情况下发生。
恶意攻击者通常使用社交工程通过聊天或电子邮件向不知情的用户发送链接。
当用户点击链接时,它将执行攻击者设置的命令。
例如,点击链接可以从用户的帐户中转移资金。或者,它可以更改用户的电子邮件地址,使他们无法重新访问他们的帐户。
CSRF袭击是如何进行的?
CSRF攻击的第一步也是最关键的一步是要求用户在登录时发起改变状态的请求。通过CSRF攻击,攻击者的目的是让经过认证的用户在不知情的情况下向网站或web应用提交恶意的网络请求。这些请求可以包括cookies、URL参数和其他用户常见的数据类型。
CSRF攻击要想成功,必须具备以下条件:
经过身份验证的用户必须登录到使用cookies进行会话管理的web应用程序。
攻击者必须创建一个假的请求来改变状态。
目标服务器处理的真实请求不应该包含不可预测的参数。例如,在开始状态改变请求之前,请求不应该期望密码作为验证参数。
完成CSRF攻击最常见的方法是在具有弱SameSite cookie策略的应用程序中使用cookie。Web浏览器自动地(通常是匿名地)包含cookie,它在用户向某个域发出的任何网络请求中保存该域使用的cookie。
SameSite cookie策略定义了在跨站点浏览的情况下浏览器如何处理cookie。如果设置为“严格”,则在跨网站浏览时不会共享cookie,从而防止CSRF攻击。如果设置为“无”,浏览器会将cookie附加到所有跨站点上下文。这使得应用程序容易受到CSRF攻击。
当用户无意中通过web浏览器提交恶意请求时,保存的cookie将使请求在服务器看来是合法的。然后,服务器通过更改用户帐户、更改会话状态或返回请求的数据来响应请求。
让我们仔细看看CSRF攻击路径的两个例子,一个是GET请求,另一个是POST请求。
获取请求的CSRF
首先,考虑一个金融银行网络应用程序使用的GET请求。攻击者利用GET请求和超链接传递。
假设传输的GET请求如下所示:
GET https://xymbank.com/online/transfer?amount=1000&accountNumber=547895 HTTP/1.1
在上面的真实请求中,用户要求向547,895的帐户转账1,000美元作为购买产品的付款。
虽然这个请求是清晰、简单和实用的,但是它使帐户持有者暴露于CSRF攻击。这是因为请求不需要攻击者可能不知道的细节。因此,为了发起攻击,攻击者只需要改变这个请求的参数(金额和账号)就可以创建一个可执行的假请求。
恶意请求对银行的任何用户都有效,只要他们正在进行cookie管理会话。
以下是向黑客账户(此处为654585)转账500美元的假请求。请注意,以下示例是对CSRF攻击中所涉及步骤的高度简化版本进行解释。
GET https://xymbank.com/online/transfer?amount=500&accountNumber=654585 HTTP/1.1
一旦完成,攻击者必须找到一种方法来欺骗用户在登录在线银行应用程序时发送这个请求。实现的方法之一就是创建一个无害的超链接来吸引用户的注意力。该链接可能如下所示:
Click here to get more information.
如果攻击者找到目标的正确电子邮件地址,他们可以通过电子邮件将其发送给许多银行客户。那些在登录时点击链接的人将触发从登录的帐户向攻击者发送500美元的请求。
员额请求的CSRF
让我们看看,如果同一个金融机构只接受POST请求,他们将如何体验CSRF。在这种情况下,GET请求示例中使用的超链接传递将不起作用。因此,成功的CSRF攻击需要攻击者创建一个HTML表单。为购买的产品发送1,000美元的真实请求如下所示:
POST /online/transfer HTTP/1.1Host: xymbank.comContent-Type: application/x-www-form-urlencodedCookie: session=FRyhityeQkAPzeQ5gHgTvlyxHJYhgamount=1000account=547895
这个POST请求需要一个cookie来确定用户的身份、他们希望发送的金额以及他们希望发送的帐户。攻击者可以改变这个请求进行CSRF攻击。
通过将真实的cookie添加到虚假的请求中,攻击者可以让服务器处理传输。他们可以通过创建一个看起来无害的超链接,将用户带到一个类似这样的触发网页。
document.forms[0].submit();
我们已经在上表中设置了金额和账户参数。经过身份验证的用户访问该页面后,浏览器会在将请求转发到服务器之前添加一个会话cookie。然后,服务器将500美元转到黑客的账户上。
减少CSRF攻击的3种方法
有几种方法可以防止并大大减轻对您的网站或web应用程序的潜在CSRF攻击,包括:
使用CSRF令牌
使用推荐人标题
选择安全的托管解决方案。
如何使用CSRF令牌防止CSRF攻击
CSRF安全网站将为每个会话分配一个唯一的令牌,并与服务器和客户端浏览器共享。每当浏览器发送敏感请求时,服务器都希望它包含指定的CSRF令牌。如果它有错误的令牌,服务器将丢弃它。出于安全原因,CSRF令牌不存储在客户端浏览器的会话cookies中。
CSRF令牌的潜在漏洞
虽然CSRF令牌是一种很好的安全措施,但这种方法是不抗攻击的。伴随CSRF令牌的一些漏洞包括。
绕过身份验证–如果没有找到令牌,一些应用程序会跳过身份验证步骤。如果攻击者获得包含令牌的代码的访问权限,他们可以删除令牌并成功执行CSRF攻击。因此,如果对服务器的有效请求如下所示。
POST /change_passwordPOST body:password=pass123&csrf_token=93j9d8eckke20d433
攻击者只需要删除令牌,然后像这样发送它就可以执行攻击:
POST /change_passwordPOST body:password=pass123
池令牌—一些应用程序维护令牌池来验证用户会话,而不是为会话指定特定令牌。攻击者只需获得池中的令牌,就可以冒充网站的任何用户。
攻击者可以使用他们的帐户登录应用程序以获取令牌,例如:
[application_url].com?csrf_token=93j9d8eckke20d433
由于令牌是池化的,攻击者可以复制并使用同一个令牌登录不同的用户帐户,因为您会再次使用它:
CSRFs可以将令牌复制到cookie中——一些应用程序会将与令牌相关的参数复制到用户的cookie中。如果攻击者获得了这样的cookie,他们可以很容易地创建另一个cookie,将其放入浏览器,并执行CSRF攻击。
因此,攻击者可以使用他们的帐户登录应用程序,打开cookie文件并看到以下内容:
Csrf_token:93j9d8eckke20d433
然后,他们可以使用此信息创建另一个cookie来完成攻击。
的令牌无效–某些应用程序的CSRF令牌与用户会话不匹配。在这种情况下,攻击者实际上可以登录到一个会话,获得一个类似于上面的CSRF令牌,并使用它来计划对受害者会话的CSRF攻击。
如何利用引用头防止CSRF攻击
防止CSRF攻击的另一个策略是使用referrer头。在HTTP中,referrer头指示请求的来源。它们通常用于分析、优化和记录。
您也可以在服务器端启用检查referrer头,以防止CSRF攻击。服务器端检查请求的来源,并确定请求的目标来源。如果它们匹配,则请求被允许。如果不匹配,服务器将放弃请求。
使用referrer标志比使用token容易得多,因为它不需要单独的用户标识。
引用标头的潜在漏洞
像CSRF标签一样,引用头信息也有一些重要的漏洞。
首先,Referrer头文件不是强制的,有些网站会发送没有Referrer头文件的请求。如果CSRF没有处理没有报头信息的请求的策略,攻击者可以使用带有报头信息的请求来执行状态改变攻击。
此外,随着最近referrer策略的引入,这种方法不再有效。该规范防止URL泄漏到其他域,并让用户能够更好地控制referrer头中的信息。他们可以选择公开部分referrer头信息,或者通过向HTML页面添加元数据标签来禁用它,如下所示。
上述代码删除了该页面上所有请求的referrer标头。这使得依赖引用头的应用程序很难阻止来自这种页面的CSRF攻击。
总结
跨站请求伪造(CSRF)是一种攻击,它欺骗经过身份验证的用户无意中发起更改状态的请求。它们针对的是无法区分有效和伪造状态更改请求的应用程序。
CSRF只能在依赖会话cookie来识别登录用户并且具有弱的SameSite cookie策略的应用程序上取得成功。他们还需要一台接受不包含未知参数(如密码)的请求的服务器。黑客可以使用GET或POST发送恶意攻击。
虽然使用CSRF令牌或强制引用头验证可以防止一些CSRF攻击,但这两种措施都有潜在的漏洞,如果不小心,会使您的预防措施无效。