CSRF概述
Posted WEB漏洞挖掘
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了CSRF概述相关的知识，希望对你有一定的参考价值。
在本节中，我们将解释什么是跨站请求伪造，描述一些常见的CSRF漏洞示例，并解释如何防止CSRF攻击。
1. CSRF是什么
跨站请求伪造(也称为CSRF)是一个web安全漏洞，它允许攻击者诱导用户执行他们不打算执行的操作。它使得攻击者能够一定程度上绕过同源策略，该策略旨在防止不同网站相互干扰。
2. CSRF攻击的影响是什么
3. CSRF攻击原理
要使CSRF攻击成为可能，必须具备三个关键条件:
一个重要的操作。在应用程序中存在攻击者有理由诱导的操作。这可能是一个特权操作(如修改其他用户的权限)或对特定用户数据的任何操作(如更改用户自己的密码)。
基于cookie的会话处理。执行操作涉及发出一个或多个HTTP请求，应用程序仅依赖会话cookie来识别发出请求的用户。没有其他机制可以跟踪会话或验证用户请求。
没有不可预知的请求参数。执行该操作的请求不包含攻击者无法确定或猜测的任何参数。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，该功能就不会受到攻击。
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 cookies)。
尽管CSRF通常与基于cookie的会话处理相关，但它也会出现在应用程序自动向请求添加一些用户凭证的其他场景中，如HTTP Basic身份验证和基于证书的身份验证。
4. 如何构造CSRF攻击
手动创建CSRF利用所需的HTML可能很麻烦，特别是所需的请求包含大量参数，或者请求中有其他古怪之处。构建CSRF漏洞的最简单方法是使用Burp Suite Professional中内置的CSRF PoC生成器:
在Burp Suite Professional中选择你想要测试或利用的请求。
从右键菜单中，选择Engagement tools/ Generate CSRF PoC。
Burp Suite将生成一些HTML，将触发选定的请求(无cookie，它将由受害者的浏览器自动添加)。
你可以调整CSRF PoC生成器中的各种选项，以微调攻击的各个方面。在一些不寻常的情况下，你可能需要这样做，以处理请求的古怪特性。
将生成的HTML复制到网页中，先在浏览器中登录漏洞站点，然后再访问刚刚构造的页面。测试预期的请求是否成功发出，预期的操作是否发生。
5. 如何发起CSRF利用
CSRF攻击的发起机制与反射型XSS的发起机制本质上是相同的。通常，攻击者会将恶意HTML放到他们控制的网站上，然后诱使受害者访问该网站。这可以通过电子邮件或社交媒体信息向用户提供网站链接来实现。或者，如果攻击被放置在一个流行的网站(例如，在用户评论中)，他们可能只是等待用户访问该网站。
<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">
6. CSRF防御
防范CSRF攻击的最直接的方法是在相关请求中包含一个CSRFtoken。token应该是:
高熵不可预测，就像一般的会话token一样。
绑定到用户会话。
在执行相关操作之前，对每个token进行严格的验证。
对CSRF部分有效的另一种防御措施是SameSite cookie，它可以与CSRFtoken一起使用。
7. 常见的CSRF漏洞
大多数有趣的CSRF漏洞是由于在验证CSRFtoken时所犯的错误而产生的。
在前面的例子中，假设应用程序现在在更改用户密码的请求中包含一个CSRFtoken:
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的攻击。
7.1 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
7.2 CSRF token的验证取决于token是否存在
有些应用程序在token出现时正确地验证它，但如果token不存在，则跳过验证。
在这种情况下，攻击者可以删除包含token的整个参数(而不仅仅是它的值)，以绕过验证并交付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
7.3 CSRF token没有绑定到用户会话
有些应用程序不验证token是否属于发出请求的用户的同一个会话。相反，应用程序维护它已经发出的token的全局池，并接受这个池中出现的任何token。
在这种情况下，攻击者可以使用自己的帐户登录应用程序，获取有效的 token，然后在CSRF攻击中将该 token提供给受害者用户。
7.4 CSRF token绑定到非会话cookie
在上述漏洞的一个变体中，一些应用程序确实将CSRF token绑定到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的行为，那么就可能发生攻击。攻击者可以使用自己的帐户登录应用程序，获取有效的 token和关联的cookie，利用cookie设置行为将其cookie放置到受害者的浏览器中，并在CSRF攻击中将其 token提供给受害者。
cookie设置行为甚至不需要在与CSRF漏洞相同的web应用程序中存在。如果被控制的cookie具有合适的范围，那么在相同的DNS域内的任何其他应用程序都可能被用来在目标应用程序中设置cookie。例如，staging.demo.normal-website.com上的cookie设置功能可以用来放置提交到secure.normal-website.com的cookie。
7.5 CSRF token只是在cookie中复制
在上述漏洞的进一步变体中，一些应用程序不维护已发出的 token的任何服务器端记录，而是在cookie和请求参数中复制每个 token。当后续请求验证时，应用程序只验证请求参数中提交的token与cookie中提交的值是否匹配。这有时被称为针对CSRF的“double submit”防御，之所以提倡这种防御，是因为它实现起来很简单，并且避免了任何服务器端状态的需要:
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攻击。在这里，攻击者不需要获得他们自己的有效 token。他们只需发明一个 token(如果要检查的话，可能会使用所需的格式)，利用cookie设置行为将他们的cookie放置到受害者的浏览器中，并在CSRF攻击中将他们的 token提供给受害者。
8. 基于referer头防御CSRF
除了使用CSRF token的防御之外，一些应用程序还利用HTTP Referer头试图防御CSRF攻击，通常是通过验证请求来自应用程序自己的域。这种方法通常不太有效，而且经常会被绕过。
HTTP Referer头(在HTTP规范中无意中拼写错误)是一个可选的请求报头，包含链接到被请求资源的web页面的URL。它通常是在用户触发HTTP请求(包括单击链接或提交表单)时由浏览器自动添加的。有各种方法允许链接页保留或修改Referer头的值。这通常是出于保护隐私的原因。
8.1 referer的验证取决于header是否存在
有些应用程序在请求中验证Referer头，但如果该头不存在则跳过验证。
在这种情况下，攻击者可以删除受害用户的浏览器请求中的Referer头来设计他们的CSRF攻击。有多种方法可以实现这一点，但最简单的方法是在承载CSRF攻击的HTML页面中使用META标签:
<meta name="referrer" content="never">
8.2 referer验证可以被绕过
有些应用程序以一种简单的方式验证Referer头，这种方式可以被绕过。例如，如果应用程序验证了Referer中的域以期望的值开始，那么攻击者可以将其作为自己域的子域:
http://vulnerable-website.com.attacker-website.com/csrf-attack
同样地，如果应用程序只是验证Referer是否包含它自己的域名，那么攻击者可以在URL的其他地方放置所需的值:
http://attacker-website.com/csrf-attack?vulnerable-website.com
尽管你可以使用Burp识别这种行为，但当你在浏览器中测试概念验证时，你通常会发现这种方法不再有效。为了减少敏感数据以这种方式泄露的风险，许多浏览器现在默认从Referer头删除查询字符串。
你可以通过确保包含你的漏洞的响应设置了Referrer- policy: unsafe-url头信息来推翻此行为(注意在本例中Referrer的拼写是正确的，只是为了确保你正在关注!)这将确保发送完整的URL，包括查询字符串。
以上是关于CSRF概述的主要内容，如果未能解决你的问题，请参考以下文章