跨站点请求伪造–什么是CSRF攻击以及如何预防

梅根·卡扎诺夫斯基(Megan Kaczanowski)

跨站点请求伪造或CSRF是在恶意站点或程序使用户的浏览器在通过身份验证后导致用户的浏览器对受信任的站点执行不需要的操作时发生的。任何恶意行为都限于对用户进行身份验证的网站的功能。

例如,Jane可能会在查看电子邮件时登录其在线银行门户。在此期间,她可以单击网络钓鱼电子邮件中的链接(可能被链接缩短站点所混淆),其中包括要求Jane的银行将钱转入攻击者控制的帐户的请求。

由于Jane已通过其银行进行身份验证,因此他们自动执行交易,并认为由于Jane的浏览器要求其已授权该交易。

什么是HTTP请求和Cookie?

HTTP GET请求

这是用于从Web服务器请求数据的请求(例如,键入URL(请求网站)导致加载)。

HTTP POST请求

这是用于将数据发送到Web服务器的请求(例如,Web表单提交)。

某些GET和POST请求是自动触发的,无需用户交互(例如获取搜索建议或使用img src属性加载图像内容)。

会话Cookie

会话cookie是HTTP处理状态的一种方式(因为它不能本地处理状态)。网站使用会话cookie(包含唯一ID)来标识用户并保留其会话。

设置后,用户的浏览器会将cookie发出的每个请求发送到服务器,以识别站点的用户。

攻击者可以通过迫使用户的浏览器执行请求来利用Cookie来冒充用户。如果用户已经登录到站点,则cookie将随请求自动发送。

跨站点请求伪造如何工作?

为了使攻击者能够进行CSRF攻击,需要满足以下几项要求:

  • 攻击者想要在应用程序中执行一项操作,例如更改密码,转移资金等。
  • 没有不可预测的请求参数-攻击者可以猜测(或知道)应用程序希望从此类请求中看到的所有参数。
  • 该操作可以由HTTP请求执行,并且仅依赖cookie来验证请求是否来自用户。

CSRF可能会影响使用Cookie,浏览器身份验证或客户端证书对用户进行身份验证的Web应用程序。本质上,它可以在应用程序自动将用户的凭据或身份附加到请求的任何情况下发生。

CSRF攻击可以利用GET请求或POST请求(尽管POST请求更为复杂,因此并不常见)。

要么需要先从攻击者身上诱骗受害者将信息加载或提交到Web应用程序。这可以通过多种方式进行,例如通过网络钓鱼链接。

另外,类似于XSS(跨站脚本),CSRF可以是存储的漏洞。当攻击者将攻击存储在接受HTML(例如IMG或IFRAME标签)的字段中时,就会发生存储的CSRF。这意味着查看该页面的任何人都可能受到影响。该漏洞利用程序可以伪装成普通链接,也可以隐藏在图像标签中。

例如,作为网页上的普通链接: <a href=“malicious link”>Unsubscribe here</a>

或者,作为图像标签: <img src=“malicious link” width=“0” height=“0” border=“0”>

CSRF的例子

想象一下,您的银行(bank.com)使用GET请求处理转账,该请求包含多个参数(转账接收者的身份以及您要转账的金额)。

例如,如果Jim要向他的朋友Bob寄10美元,则请求可能看起来像这样:

http://bank.com/transfer?recipient=Bob&amount=10

该请求还包括一个会话cookie,该会话cookie标识了帐户所有者,因此银行知道从何处取钱。

现在,攻击者可能会说服吉姆单击看起来像这样的链接(但已被URL缩短器缩短或巧妙地超链接了):

http://bank.com/transfer?recipient=Hacker&amount=100000

因为吉姆已经登录,所以他的浏览器将其请求发送给他的cookie –因此他的银行认为他正在请求转帐并且该转帐已完成。

如何停止CSRF攻击

仔细选择您的框架

使用内置了针对CSRF的保护的框架,例如.NET。正确的配置是关键。如果您使用的框架没有保护,则可以使用Anti-CSRF令牌添加保护。

使用反CSRF令牌

令牌(也称为同步器令牌模式)是一种服务器端保护,其中服务器为用户的浏览器提供一个唯一的,随机生成的令牌,并在执行请求之前检查每个请求以查看浏览器是否将其发回。

该令牌是通过隐藏字段发送的,并且应该是不可预测的随机数,它会在短时间后过期,并且无法重复使用。

根据页面的敏感度,每个请求可以使用不同的令牌,也可以仅将它们用于不同的形式。应该以安全的方式比较令牌(例如,通过比较哈希),并且不应该在HTTP get请求中发送令牌,因此它们不是URL的一部分,并且不能通过Referrer标头泄漏。

在Cookie中使用SameSite标志

SameSite标志标记一个cookie,因此只能针对来自同一域的请求发送该cookie。

本质上,如果www.bank.com希望向发出请求www.bank.com/updatepassword,则允许这样做。但是,如果www.maliciousdomain.com要向www.bank.com/updatepassword发出请求,它将无法发送会话cookie,因此无法进行攻击。

现在,大多数浏览器都支持该标志,但并非全部。它应该成为全面防御战略的一部分。

深度实践防御

您可以实现许多其他控件,这些控件与其他措施一起使用时,可以提供针对CSRF的保护。

例如,以下是您可以设置的其他一些保护措施:

  • 使用标准标头验证来源(确定请求的起源和目标,以确保它们匹配)
  • 使用自定义请求标头(这样,如果没有标头,网站将不会接受该请求)
  • 两次提交cookie(对于攻击者来说,本质上是第二个,随机生成的且未知的参数,攻击者必须随请求一起提交该参数,才能使请求成功)。

让用户参与交易

对于诸如汇款或更改密码之类的敏感操作,要求用户采取操作(例如CAPTCHA,一次性令牌或重新认证)。

无效措施的示例:

  • 多步骤事务:只要攻击者可以预测/确定每个步骤,那么有多少步都没有关系。
  • HTTPS:始终是一个好主意,但没有采取任何措施来防御CSRF。
  • URL重写:这将防止攻击者在CSRF攻击期间猜测受害者的会话ID,但随后将允许攻击者在URL中看到它。将一个缺陷换成另一个缺陷不是一个好主意。
  • 使用秘密Cookie:即使秘密Cookie也作为请求的一部分提交,这意味着攻击者仍然可以利用它。
  • 仅接受POST请求/避免GET请求:伪造的POST请求仍可用于执行CSRF攻击。

CSRF的其他名称

CSRF也被称为XSRF,海上冲浪,会话骑马,跨站点引用伪造,敌对链接,一键式攻击。

点击阅读原文

本文来自投稿,不代表微擎百科立场,如若转载,请注明出处:https://www.w7.wiki/develop/5162.html

发表评论

登录后才能评论