什么是跨站请求伪造CSRF | 案例与防护方法

组织若希望全面保护资源安全，免受网络漏洞造成的损害，必须更新知识并熟悉所有现有漏洞类型。CSRF是本文重点讨论的内容。

什么是CSRF攻击？

作为XSS的对应物，CSRF是众多网络漏洞之一，其中授权用户被迫在已认证的网站上执行不可接受或未经授权的操作。通过双因素登录、密码等方式，网站对最终用户进行身份验证，并允许他们访问网站/应用程序的服务/功能。这样，最终用户和网站之间建立了信任。

威胁行为者利用这种信任因素，通过CSRF攻击获得对网站的未经授权访问。CSRF有许多同义词，包括恶意链接、Sea Surf、会话劫持、一键攻击等。

值得关注的CSRF攻击特征如下：

在跳过验证操作是否获得用户同意的网站/Web应用程序上易于执行
XSS涉及网站侵犯用户隐私，而CSRF涉及用户利用网站的情况
不需要使用JavaScript或任何其他类型的代码即可成功执行
单页面应用程序更可能成为CSRF受害者，因为它们将CSRF令牌存储为cookie，这是威胁行为者的最爱

什么是CSRF令牌？

CSRF令牌对于尽可能降低CSRF攻击的发生可能性至关重要，它是一个安全的、每个会话唯一的随机生成的令牌。挑战令牌和同步器令牌是最常见的例子。

CSRF令牌必须集成在用于服务器端功能的HTML表单的隐藏/不可见组件中，并与最终用户的浏览器共享。其体积必须足够大，以便威胁行为者无法理解。

启用CSRF的网站和Web应用程序将为各个HTTP请求或登录会话生成专属的CSRF令牌。

正确验证CSRF令牌将阻止CSRF攻击。但是，某些因素会影响CSRF令牌验证：

验证受请求类型的影响很大。例如，某些网站会完全验证HTTP POST请求，而拒绝GET请求
令牌的可用性也会影响验证。例如，如果在某个时间点没有令牌，请求将被忽略

CSRF如何工作？

执行CSRF攻击需要满足3个条件：

网站上发生特权操作，例如导致更改用户关注数据的操作
目标站点在用户身份验证期间必须使用至少1个HTTP请求，同时启用会话cookie
用户请求的任何部分对攻击者都不是隐藏或不可读的

一旦满足所有这三个条件，就可以执行CSRF攻击。

在欺骗用户发起伪造请求方面，CSRF具有高度多样性。在了解这些方式之前，让我们通过一个示例了解如何创建恶意请求。

示例

假设John需要通过money.com网站向Jena转账500美元。

现在，money.com网站没有强大的CSRF保护，威胁攻击者Leo利用这个机会接收John试图转账的资金。

为实现这一目标，攻击者Leo将按以下步骤进行：

创建 manipulated脚本或URL
通过社交工程诱使John使用被篡改的URL/脚本

现在，让我们了解CSRF攻击在不同场景下的工作方式：

当网站接受GET请求时

在这种情况下，John发起的转账请求将如下所示：

1

GET http://money.com/transfer.do?acct=JENA&amount=500 HTTP/1.1

威胁行为者Leo将通过John利用这一点。首先，他将创建一个被篡改的URL，将John发起的资金转账定向到他的银行账户。

他将访问John的转账命令，并将Jena的名字替换为自己的名字。他还可以更改转账金额。被利用的命令将如下所示：

1

http://money.com/transfer.do?acct=LEO&amount=5000

在被利用的URL中，Leo将原始转账金额替换为5,000美元。

在这里，包含HTML内容的电子邮件或将滥用的URL放置在已验证页面前面的社交工程策略欺骗John加载被利用的URL。由于被更改的页面/URL/脚本与原始URL/脚本/页面非常相似，很容易被欺骗。

当网站接受POST请求时

如果网站仅获取POST请求，则John的命令将如下所示：

1
2


POST http://money.com/transfer.do HTTP/1.1
acct=JENA&amount=500

现在，此类请求通过FORM标签传递：

1
2
3
4
5


<form action="http://money.com/transfer.do" method="POST">
<input type="hidden" name="acct" value="Leo"/>
<input type="hidden" name="amount" value="5000"/>
<input type="submit" value="Check my pictures"/>
</form>

使用FORM标签强制点击提交按钮以完成请求提交。或者，请求可以通过JavaScript的实用性自动呈现。

当网站使用其他HTTP方法时

除了GET和POST，其他HTTP请求模式如PUT和DELETE也经常使用。基于PUT的HTTP请求将在被篡改的页面/URL中具有JavaScript。由于我们目前使用的先进浏览器强制执行同源策略，通常不会看到针对PUT和DELETE请求的CSRF攻击。

如何检测跨站请求伪造？

无论漏洞类型如何，早期检测都是控制损害的关键。

有助于及时检测CSRF的最实用指标是：

允许通过GET请求进行会话管理的网站。第三方可以轻松访问此类站点。因此，它们更容易受到CSRF攻击。确保您的网站不在其中
Web代理在CSRF检测中非常有用。由于它跟踪HTTP请求从开始到结束的旅程，您可以在不与应用程序的客户端界面启动交互的情况下重放请求

如何预防CSRF攻击？

如果不首先处理，CSRF攻击可能导致数据威胁、资金窃取、登录详细信息更改，甚至失去对关键应用程序的控制。因此，除了早期检测外，还应部署可行的CSRF预防策略。

基于CSRF令牌的预防

防御CSRF攻击的主要方法是确定HTTP请求是否合法创建，即仅使用应用程序的用户界面。网站所有者或管理员可以利用CSRF令牌。

应用程序安全团队应找出服务器端功能中易受攻击的部分，并在该易受攻击操作部分的HTML表单中引入CSRF令牌。

确保预期的HTML表单不是会话cookie的组成部分。此外，利用加密安全的随机数生成器进行令牌创建。

利用SameSite Cookie属性

它通常用于极大地支持CSRF攻击预防方法。与Secure Flag和HTTPOnly有很多共同点，它充分装备浏览器以同时处理cookie和跨站点请求。

其可接受值如下所列：

“Strict"值将阻止通过浏览传输cookie
“Lax"是默认值，当Web解决方案希望允许包含外部链接的用户访问请求时维护安全。目前，大多数浏览器都具有此功能，作为在使用CSRF令牌的同时防御CSRF攻击的附加防线
当您希望使用cookie访问跨站点URL时，使用"none"值

利用用户交互进行CSRF保护

这是实现CSRF预防策略的最简单方法。它涉及重新认证、一次性令牌创建和CAPTCHA部署的使用。所有这些技术都增加了用户交互，并减少了威胁攻击闯入的范围。此外，它增强了用户体验。

控制登录CSRF

许多开发人员未能理解CSRF可以存在于登录表单中并造成损害的事实。这就是为什么它大多被忽略的原因。可以通过为每个用户生成预会话并在这些会话中引入CSRF令牌来防止CSRF影响登录表单。这使得早期身份验证安全。但是，请确保一旦启动真实会话，此预会话应被销毁。忽略这一点将邀请会话固定攻击。

双重提交cookie

此方法通常用作CSRF防御策略。它涉及将类似的令牌值存储在cookie中而不是服务器会话中。这样做鼓励了类似cookie的CSRF令牌转发，同时将隐藏字段/值与其关联。收到请求后，服务器需要确定存储在隐藏字段和cookie中的CSRF值是否匹配。

如何防止JavaScript中的CSRF攻击？

希望防止JavaScript受到CSRF攻击的安全专家可以使用自定义请求头，因为它依赖于SOP或同源策略方法来保护应用程序的JavaScript部分。此标头只能隐含在JavaScript的源上。但是，浏览器默认不允许JavaScript创建自定义标头。

这种方法带来双重好处，例如不需要对UI进行任何更改，并且不需要呈现服务器端状态。

是否有必要保护API免受CSRF攻击？

CSRF攻击一直在上升，没有例外。

由于API使用量增加并且对Web和移动应用程序开发至关重要，它已成为CSRF攻击的重要目标。当API成为CSRF攻击的受害者时，整个数字解决方案或应用程序都会受到威胁。

为了强大的API安全性，保护API免受CSRF攻击至关重要。针对API的CSRF攻击可以轻松预防。

应限制对内容类型应用程序或JSON的API请求。这样，CSRF攻击的可能性较小。通过内容类型完成的API请求更安全
API访问令牌应呈现在请求头上。此外，API应忽略基于cookie的CSRF令牌
基于JavaScript的单页面应用程序应仅构建为使用cookie进行存储。此类应用程序还应完成将身份验证令牌作为标头传输到API，并且不应接受缺少标头的请求

原文发表于：https://www.wallarm.com

跨站请求伪造(CSRF)详解：攻击原理与防护方法

本文深入解析跨站请求伪造(CSRF)攻击的工作原理，通过实际案例展示攻击过程，详细介绍CSRF令牌、SameSite Cookie属性等多种防护措施，帮助开发者有效防范此类安全威胁。