CSRF跨站请求伪造

最新推荐文章于 2024-09-04 15:15:31 发布

海绵宝宝救赎

最新推荐文章于 2024-09-04 15:15:31 发布

阅读量879

点赞数 16

文章标签： csrf 网络安全 web安全

本文链接：https://blog.csdn.net/m0_72372037/article/details/134817828

版权

什么是CSRF

跨站请求伪造(也称为CSRF)，允许攻击者诱使用户执行他们不打算执行的操作，允许攻击者部分规避同源策略，该策略在防止不同网站相互干扰

CSRF攻击的影响？

在成功的CSRF攻击中，攻击者会使受害用户无意执行操作
例如：可能是更改其账户上的电子邮件地址，更改其密码或进行资金转账，根据操作的性质，攻击者可能能够完全控制用户账户，如果被入侵的用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有数据和功能

CSRF如何工作的？

CSRF攻击，需满足三个关键条件：

相关操作，应用程序中存在攻击者有理由诱发的操作，这可能是特权操作(例如：修改其他用户的权限)，或对用户特定数据的任何操作(如：更改用户自己的密码)
基于cookie的会话处理，执行该操作设计发出一个或多个HTTP请求，应用程序仅依靠会话cookie来识别发出请求的用户，没有其他机制可用于跟踪会话或验证用户请求
没有不可预测的请求参数，执行操作的请求不包含任何攻击者无法确定或猜测其值的参数，如：当导致用户更改其密码时，如果攻击者需要知道现有密码的值，则该功能不容易受到攻击
例如，假设应用程序包含允许用户更改其帐户上的电子邮件地址的函数。当用户执行此操作时，他们会发出如下所示的 HTTP 请求：

POST /email/change HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE email=wiener@normal-user.com

这满足 CSRF 所需的条件：

攻击者对更改用户帐户上的电子邮件地址的操作感兴趣。执行此操作后，攻击者通常能够触发密码重置并完全控制用户帐户。
应用程序使用会话 cookie 来标识发出请求的用户。没有其他令牌或机制来跟踪用户会话。
攻击者可以轻松确定执行操作所需的请求参数的值。

满足这些条件后，攻击者可以构建包含以下 HTML 的网页：

<html>    <body>        <form action="https://vulnerable-website.com/email/change" method="POST">            <input type="hidden" name="email" value="pwned@evil-user.net" />        </form>        <script>            document.forms[0].submit();        </script>    </body> </html>

如果受害用户访问攻击者的网页，将发生以下情况：

攻击者的页面将触发对易受攻击的网站的 HTTP 请求。
如果用户登录到易受攻击的网站，则其浏览器将自动在请求中包含其会话 cookie（假设未使用 SameSite cookie）。
易受攻击的网站将以正常方式处理请求，将其视为由受害用户发出，并更改其电子邮件地址。

关键点

受害者没有退出登录，受害者保持身份认证
CSRF 继承了受害者的身份和特权，代表受害者执行非本意的、恶意的操作
CSRF 会借用浏览器中与站点关联的所有身份凭据，例如用户的会话Cookie，IP 地址，Windows 域凭据等

注意：

尽管 CSRF 通常与基于 cookie 的会话处理相关，但它也出现在应用程序自动向请求添加一些用户凭据的其他上下文中，例如 HTTP 基本身份验证和基于证书的身份验证。

CSRF 漏洞利用

跨站请求伪造攻击的传递机制与反射型 XSS 的传递机制基本相同。
通常，攻击者会将恶意 HTML 放置在他们控制的网站上，然后诱使受害者访问该网站。可以通过通过电子邮件或社交媒体消息向用户提供指向网站的链接来完成。
或者，如果攻击被放置在一个网站中（例如，在用户评论中），他们可能只是等待用户访问该网站。

注意，一些简单的 CSRF 漏洞利用采用 GET 方法，并且可以通过易受攻击的网站上的单个 URL 完全独立。在这种情况下，攻击者可能不需要使用外部站点，并且可以直接向受害者提供易受攻击域上的恶意 URL。在前面的示例中，如果可以使用 GET 方法执行更改电子邮件地址的请求，则自包含攻击将如下所示：

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

针对 CSRF 的常见防御

CSRF 令牌 CSRF 令牌是由服务器端应用程序生成并与客户端共享的唯一、机密且不可预测的值。尝试执行敏感操作（例如提交表单）时，客户端必须在请求中包含正确的 CSRF 令牌。这使得攻击者很难代表受害者构建有效的请求。
SameSite Cookie - SameSite 是一种浏览器安全机制，用于确定网站的 Cookie 何时包含在来自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话 Cookie，因此适当的 SameSite 限制可能会阻止攻击者跨站点触发这些操作。自 2021 年起，Chrome 默认强制执行 SameSite 限制。由于这是拟议的标准，我们预计其他主要浏览器将来也会采用这种行为。Lax
基于 Referer 的验证 - 某些应用程序利用 HTTP Referer 标头来尝试防御 CSRF 攻击，通常是通过验证请求是否来自应用程序自己的域。这通常不如 CSRF 令牌验证有效。