跨站请求伪造CSRF（Cross-site request forgery）

 

目录

一、什么是CSRF

二、可能存在CSRF攻击的三个条件

一个相关的动作

基于 Cookie 的会话处理

没有不可预测的请求参数

二、常见的CSRF攻击

        1、CSRF令牌的验证取决与请求方法

       2、CSRF令牌的验证取决与令牌是否存在

      3、CSRF令牌没有绑定到会话

      4、CSRF令牌绑定到非会话cookie

        5、CSRF令牌复制于COOKIE

        6、基于Referer的CSRF防御

                1)Referer的验证取决于是否存在

                2)可绕过的Referer

---

来自PortSwiggerr靶场

一、什么是CSRF

        跨站请求伪造（也称为 CSRF）是一种 Web 安全漏洞，允许攻击者诱导用户执行他们不打算执行的操作。它允许攻击者部分规避同源策略，该策略旨在防止不同网站相互干扰。

二、可能存在CSRF攻击的三个条件

• 一个相关的动作

        应用程序中存在攻击者有理由诱导的操作。这可能是特权操作（例如修改其他用户的权限）或对用户特定数据的任何操作（例如更改用户自己的密码）。

• 基于 Cookie 的会话处理

        执行该操作涉及发出一个或多个 HTTP 请求，并且应用程序仅依赖会话 cookie 来识别发出请求的用户。没有其他机制可用于跟踪会话或验证用户请求。

• 没有不可预测的请求参数

        执行该操作的请求不包含攻击者无法确定或猜测其值的任何参数。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，则该功能不会受到攻击。        

二、常见的CSRF攻击

        1、CSRF令牌的验证取决与请求方法

        某些应用程序在请求使用 POST 方法时正确验证令牌，但在使用 GET 方法时跳过验证。
在这种情况下，攻击者可以切换到 GET 方法来绕过验证并进行 CSRF 攻击：

GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLmGET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

 

       2、CSRF令牌的验证取决与令牌是否存在

        某些应用程序在令牌存在时正确验证令牌，但如果省略令牌则跳过验证。
在这种情况下，攻击者可以删除包含令牌的整个参数（不仅仅是它的值）以绕过验证并进行 CSRF 攻击：
 

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 25
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm

email=pwned@evil-user.net

      3、CSRF令牌没有绑定到会话

        某些应用程序不会验证令牌与发出请求的用户是否属于同一会话。相反，应用程序维护它已发布的全局令牌池，并接受该池中出现的任何令牌。
在这种情况下，攻击者可以使用自己的帐户登录应用程序，获取有效令牌，然后在 CSRF 攻击中将该令牌提供给受害用户。

      4、CSRF令牌绑定到非会话cookie

        在上述漏洞的一个变体中，一些应用程序确实将 CSRF 令牌绑定到一个 cookie，但没有绑定到用于跟踪会话的同一个 cookie。当应用程序使用两个不同的框架时，很容易发生这种情况，一个用于会话处理，一个用于 CSRF 保护，它们没有集成在一起：

 

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=pSJYSScWKpmC60LpFOAHKixuFuM4uXWF; csrfKey=rZHCnSzEp8dbI6atzagGoSYyqJqTz5dv

csrf=RhV7yQDO0xcq9gLEah2WVbmuFqyOq7tY&email=wiener@normal-user.com

        这种情况更难利用，但容易受到攻击。如果网站包含任何允许攻击者在受害者的浏览器中设置 cookie 的行为，则攻击是可能的。攻击者可以使用自己的帐户登录应用程序，获取有效的令牌和关联的 cookie，利用 cookie 设置行为将其 cookie 放入受害者的浏览器，并在 CSRF 攻击中将其令牌提供给受害者。

        5、CSRF令牌复制于COOKIE

             在上述漏洞的进一步变体中，一些应用程序不维护已颁发令牌的任何服务器端记录，而是在 cookie 和请求参数中复制每个令牌。验证后续请求时，应用程序只需验证请求参数中提交的令牌与 cookie 中提交的值是否匹配。这有时被称为针对 CSRF 的“双重提交”防御，并且被提倡是因为它易于实现并且避免了对任何服务器端状态的需要：```

 

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=1DQGdzYbOJQzLP7460tfyiv3do7MjyPw; csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa

csrf=R8ov2YBfTYmzFyjit8o2hKBuoIjXXVpa&email=wiener@normal-user.com

        在这种情况下，如果网站包含任何 cookie 设置功能，攻击者可以再次执行 CSRF 攻击。在这里，攻击者不需要获取自己的有效令牌。他们只需发明一个令牌（可能是所需格式，如果正在检查的话），利用 cookie 设置行为将他们的 cookie 放入受害者的浏览器，并在他们的 CSRF 攻击中将他们的令牌提供给受害者。

        6、基于Referer的CSRF防御

        除了使用 CSRF 令牌的防御之外，一些应用程序使用 HTTPReferer标头来尝试防御 CSRF 攻击，通常是通过验证请求是否来自应用程序自己的域。这种方法通常不太有效，并且经常被绕过。

                1)Referer的验证取决于是否存在

          某些应用程序Referer会在请求中存在标头时验证标头，但如果标头被省略，则跳过验证。
在这种情况下，攻击者可以制作他们的 CSRF 漏洞利用，导致受害者用户的浏览器Referer在结果请求中丢弃标头。有多种方法可以实现这一点，但最简单的方法是在承载 CSRF 攻击的 HTML 页面中使用 META 标记：

<meta name="referrer" content="never">

                2)可绕过的Referer

        一些应用程序Referer以一种可以绕过的幼稚方式验证标头。例如，如果应用程序验证域中的域以Referer期望值开头，那么攻击者可以将其放置为他们自己域的子域：
 

http://vulnerable-website.com.attacker-website.com/csrf-attack

同样，如果应用程序只是验证Referer包含自己的域名，那么攻击者可以将所需的值放在 URL 的其他位置：

http://attacker-website.com/csrf-attack?vulnerable-website.com