跨站点请求伪造（CSRF）：影响、示例和预防

最新推荐文章于 2024-06-18 17:09:25 发布

mmxhappy

最新推荐文章于 2024-06-18 17:09:25 发布

阅读量588

点赞数 7

分类专栏：渗透测试文章标签： csrf microsoft 前端

本文链接：https://blog.csdn.net/mmxhappy/article/details/135864805

版权

渗透测试专栏收录该内容

41 篇文章 3 订阅

订阅专栏

本文详细解释了CSRF攻击的概念、影响、工作原理，探讨了CSRF令牌的作用以及常见漏洞。文章还提供了防止CSRF的策略，包括高级验证技术、Cookie属性和用户交互防御。最后强调了定期安全测试以发现和修复CSRF漏洞的重要性。

摘要由CSDN通过智能技术生成

文章目录

常见的CSRF漏洞：CSRF令牌实现中的弱点

定期执行 Web 应用程序安全测试以识别 CSRF

总结

前言

跨站点请求伪造（CSRF/XSRF），是一个 Web 安全漏洞，可诱使 Web 浏览器执行不需要的操作。因此，攻击者滥用 Web 应用程序对受害者浏览器的信任。它允许攻击者部分绕过同源策略，该策略旨在防止不同的网站相互干扰。

一、CSRF 攻击的影响是什么？

当一个网站代表用户向另一个网站发送数据请求以及用户的会话cookie时，攻击者可以发起跨站点请求伪造攻击，从而滥用受害者浏览器和网络服务器之间的信任关系。

在某些情况下，根据操作类型，攻击者可以获得用户帐户的完全控制权。如果遭到入侵的用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有功能和数据，这对业务和用户都是毁灭性的。结果可能是数据盗窃、未经授权的资金转移、客户关系受损、密码更改等等。

二、跨站点请求伪造如何工作？

当用户尝试访问站点时，浏览器通常会自动在请求中包含凭据，以使登录过程更加方便。这些凭据可能包括用户的会话 Cookie、基本身份验证凭据、IP 地址和 Windows 域凭据。

此机制固有的风险是攻击者可以轻松模拟用户。一旦用户通过网站的身份验证，网站就无法区分伪造的请求和合法的用户请求。

在CSRF攻击中，攻击者冒充受害者的身份，并在未经用户同意的情况下使用它代表用户执行操作。攻击者通常遵循以下过程：

他们使用社会工程技术说服受害者通过电子邮件、聊天消息或类似的通信形式点击链接。
恶意链接本身或用户访问的网页会触发对目标站点的请求
该请求应该来自用户，并利用用户已经登录到网站的事实。
该网站在用户不知情或不同意的情况下确认请求并执行攻击者请求的操作。

CSRF 攻击通常试图更改服务器状态，但也可用于获取对敏感数据的访问权限。如果攻击者成功对受害者的帐户执行 CSRF 攻击，他们可以转移资金、购买产品、修改帐户信息（如送货地址）、修改密码或用户登录时可用的任何其他操作。

CSRF 攻击示例

以下示例显示了 5，000 美元银行转帐的典型 GET 请求的外观：

GET https://abank.com/transfer.do?account=RandPerson&amount=$5000 HTTP/1.1

攻击者可以修改脚本，以便将 5，000 美元转入其个人帐户恶意请求可能如下所示：

GET https://abank.com/transfer.do?account=SomeAttacker&amount=$5000 HTTP/1.1

之后，攻击者能够将请求嵌入到看似无害的超链接中：

<a href="https://abank.com/transfer.do?account=SomeAttacker&amount=$5000">Click for more information</a>

下一步是通过电子邮件将超链接分发给大量银行客户。那些登录其银行帐户并单击此链接的人将无意中发起 5，000 美元的转账。

如果银行的网站仅使用 POST 请求，则无法使用 <a> href 标签构建恶意请求。但是，攻击可以通过<表单>标签进行传递。

这就是这样的表单的外观，甚至可以是自我提交的表单：

</form>

</body>

由于上面的表单没有提交按钮，因此将在用户不知情和同意的情况下触发。相反，该按钮仅由一行javascript替换：

document.getElementById('csrf').submit();

什么是CSRF令牌？

CSRF 令牌是由服务器端应用程序生成的唯一、不可预测的密钥值，并发送到客户端以包含在客户端发出的后续 HTTP 请求中。颁发令牌后，当客户端发出请求时，服务器会检查请求是否包含预期的令牌，如果令牌丢失或无效，则拒绝它。

CSRF 令牌可以防止 CSRF 攻击，因为它们可以防止攻击者形成完全有效的 HTTP 请求，这些请求可以提供给受害者。攻击者无法确定或预测用户的 CSRF 令牌的值，因此应用程序不应接受他们生成的任何请求。

常见的CSRF漏洞：CSRF令牌实现中的弱点

一些最常见的 CSRF 漏洞是由 CSRF 令牌验证过程中的错误引起的。确保您的CSRF过程没有任何这些弱点。

验证取决于令牌的存在：

在某些应用程序中，如果令牌不存在，则会跳过验证过程。这意味着攻击者只需查找包含令牌信息的代码并将其删除，应用程序不会执行令牌验证。
CSRF 令牌与用户会话无关

某些应用程序维护一个令牌池，只要使用池中的令牌，它就会被接受。但是，应用程序不会将特定令牌绑定到特定用户。攻击者只需从池中获取至少一个令牌，并可以使用它来模拟任何用户。
使用 HTTP 方法更改令牌验证

在某些应用程序中，使用 GET 方法而不是 POST 方法将导致 CSRF 验证无法正常工作。攻击者只需从 POST 切换到 GET，即可轻松绕过验证过程。
CSRF 令牌被复制到 cookie 中

某些应用程序不保留已在使用的令牌的记录。相反，他们将与每个令牌关联的请求参数复制到用户的 cookie 中。在此设置中，攻击者可以使用应用程序的预期格式创建包含令牌的 cookie，将其放置在用户的浏览器中，然后执行 CSRF 攻击。用户浏览器发送的请求将被验证，因为它将与攻击者提供的恶意cookie匹配。

CSRF 预防：超越 CSRF 代币

防止CSRF的基本方法是实现CSRF代币，同时避免我们在上一节中描述的弱点。以下是防止 CSRF 攻击的其他方法。

使用高级验证技术降低 CSRF

当表单中使用的所有参数都被识别出来时，攻击者可以发起 CSRF 攻击。因此，为了防止 CSRF 攻击，您可以添加一个附加参数，其中包含攻击者不知道的附加值，但服务器需要验证。

CSRF 攻击最广泛使用的防御技术称为反 CSRF 令牌或同步器令牌。当用户通过提交表单发出一些经过身份验证的请求时，该请求中应包含一个随机令牌。然后，网站将在处理发送的请求之前验证此令牌的发生，如果令牌丢失或值不正确，则请求将被拒绝，攻击者将无法发起CSRF攻击。

同网站 Cookie 属性

RFC 6265 之二中定义的 cookie 属性试图缓解 CSRF 攻击。该属性告诉浏览器何时可以发送带有跨站点请求的 cookie。cookie 属性带有三个可能的值 – 、或。

大多数移动浏览器和所有桌面浏览器都支持此属性。SameSiteSameSiteStrict LaxNone

该值可以告诉浏览器在跨站点浏览会话期间不要向站点发送cookie。这包括遵循常规链接的会话。例如，当用户登录到 GitHub 并浏览由公司托管的私有 GitHub 项目时，浏览器不会向 GitHub 发送会话 Cookie，从而限制对项目的访问。Strict

如果不需要允许外部站点链接到事务页面，则可以使用该标志。但是，如果您需要在可用性和安全性之间取得平衡，使由外部链接定向的用户能够维护登录会话 - 则应使用默认值。通常，在 Lax 模式下授予的跨站点请求被视为安全的 HTTP 方法。StrictLax

以下是使用 SameSite Cookie 属性的两个 Cookie 示例：

Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict

Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

基于用户交互的CSRF防御

通常，需要用户干预的防御机制可能会对用户体验产生负面影响。但是，在某些情况下，例如金融交易，实施这种类型的技术是适当且必需的。例如，您可以添加 CAPTCHA，这有助于验证它确实是人类用户而不是机器人。

一次性令牌还可以确保它是用户，而不是使用登录会话的攻击者。令牌通常发送到用户的电子邮件地址或电话号码，并使用用户先前提供的信息进行验证。此外，您可以引入重新身份验证，这有助于区分 CSRF 会话和真实用户。

登录 CSRF

许多开发人员忽略了应用程序登录表单中的CSRF漏洞。这是因为用户在此阶段尚未进行身份验证，因此开发人员认为不存在CSRF的风险。然而，这个假设并不总是正确的。攻击者可以执行登录 CSRF 攻击，这可能产生不同的影响，具体取决于应用程序。

如果您不能信任子域（例如，如果您允许用户定义自己的子域），则很难缓解登录 CSRF。在这些情况下，您可以使用严格的子域和路径级引荐来源网址标头验证来降低登录表单上的 CSRF 风险。

定期执行 Web 应用程序安全测试以识别 CSRF

即使成功解决了具有 CSRF 攻击的 Web 应用程序中的漏洞，应用程序更新和代码更改也可能在将来将您的应用程序暴露给 CSRF。Web 应用程序安全测试可帮助您持续扫描和测试 Web 应用程序中的潜在安全漏洞，包括 CSRF 漏洞。

Bright 有助于在开发过程的早期跨 Web 应用程序和 API 自动检测和修复许多漏洞，包括 CSRF。

通过将 DAST 扫描向左移动并集成到 SDLC 中，开发人员和应用程序安全专业人员可以及早检测漏洞，并在它们出现在生产环境之前对其进行修复。Bright 通过自动验证每个漏洞，在几分钟内完成扫描并实现零误报。这允许开发人员采用该解决方案并在整个开发生命周期中使用它。

扫描任何 Web 应用程序，或 REST、SOAP 和 GraphQL API 以防止 CSRF 漏洞

mmxhappy

关注

7
点赞
踩
9

收藏

觉得还不错? 一键收藏
0
评论
跨站点请求伪造（CSRF）：影响、示例和预防

跨站点请求伪造（CSRF/XSRF），是一个 Web 安全漏洞，可诱使 Web 浏览器执行不需要的操作。因此，攻击者滥用 Web 应用程序对受害者浏览器的信任。它允许攻击者部分绕过同源策略，该策略旨在防止不同的网站相互干扰。CSRF 令牌是由服务器端应用程序生成的唯一、不可预测的密钥值，并发送到客户端以包含在客户端发出的后续 HTTP 请求中。颁发令牌后，当客户端发出请求时，服务器会检查请求是否包含预期的令牌，如果令牌丢失或无效，则拒绝它。
复制链接

扫一扫