-008-
# 前言
今天我们将讨论CSRF漏洞，该漏洞可能是中/低严重性，有时它超出范围/不适用于登录和注销功能，我们将解决 portswigger lab的基本CSRF，我们会得到一些针对CSRF的常见防御。
# 什么是CSRF？
CSRF（跨站请求伪造）允许攻击者修改用户信息、密码等，并且不会直接发生攻击者想要诱骗用户单击用户已通过浏览器在应用程序上进行身份验证的链接。
假设有两个用户 Ram 是攻击者，Tom 是受害者
在这种情况下，Tom在reacted.com上创建了一个账户，并且已经通过他的浏览器进行了身份验证，如果Tom通过他的浏览器访问该网站，由于cookie，它不会要求用户名和密码再次登录
另一方面，ram发现了密码重置的CSRF漏洞，并构造了一些恶意HTML代码
<html><body><form action="reacted.com" method="POST"><input type="hidden" name="password" value="hacked" /><input type="hidden" name="password_confirmation" value="hacked" /><input type="submit" value="Submit request" /></form><script>document.addEventListener('DOMContentLoaded', function(event) {document.createElement('form').submit.call(document.getElementById('myForm'));});</script></body></html>
之后，Ram 嵌入了他的恶意代码并将其托管在 trust.com.in 上，然后将其发送给 Tom
如果他点击该链接，密码将被重置，我们可以接管他的账户
由于 Tom 已通过身份验证，reacted.com 会处理该请求并将密码更改为“hacked”，从而有效地损害了 Tom 的账户。
这种情况凸显了实施适当的安全措施（例如实施 CSRF 保护机制）以防止此类攻击的重要性。CSRF 保护通常涉及添加反 CSRF 令牌或使用同站点 cookie 或双重提交 cookie 等技术来验证请求并确保它们源自合法用户的浏览器。
现在你可以清楚地了解 CSRF 的概念了
## 为什么它超出范围且不适用于登录/注销？
这是因为该错误没有实际影响，它只是简单的登录/注销，不会做出任何有影响的更改，如果是您正在运营一家公司，并且您遇到了很多高严重性漏洞，例如 XSS、SQL 等，所以在这里你将修复高严重性或没有影响
# 寻找CSRF！！！
1. 检查状态更改操作端点：状态更改操作或更改用户数据的操作
例如，更改密码、删除账户、发送消息/电子邮件
2. 缺乏CSRF保护：检查是否有CSRF token，如果可用，可以使用一些技术进行绕过，但这并不意味一定会造成CSRF攻击
3. 确认漏洞：通过构造HTML表单或使用Burpsuite Pro生成CSRF的HTML表单来确认漏洞
有些网站没有任何CSRF token，但通过使用其他的token仍然是安全，也可以尝试绕过这个验证
“应用程序安全性优先考虑影响而不是错误分类。!!”
# 寻找CSRF
警告：在寻找此内容之前，请检查您的错误赏金计划的范围 实验室：没有防御的 CSRF 漏洞：在这个实验室中，没有针对 CSRF 漏洞的防护
## 首次登录/注册该应用程序
您可以使用以下凭据登录您的帐户：wiener:peter
## 查找状态更改操作端点：
包括密码更改、电子邮件更改、地址更改、删除账户、发送消息
上述端点是示例，您可以选择任何高严重性操作端点，使用户的更改程度较高
这里有一个电子邮件更新端点，您可以更改邮件
## 缺乏CSRF保护：使用burpsuite检查是否缺乏CSRF保护
首先，输入任意邮件ID [email protected]并在 burp 中捕获该请求，并检查正文或cookie中是否有CSRF token
它看起来像这样
[csrf_token="e1f55fd7a4b0c8d7c32a3be95a38f6bc"]
检查标头
X-CSRF：e1f55fd7a4b0c8d7c32a3be95a38f6bc
所以没有CSRF令牌
## 构造HTML表单来确认次漏洞
如果你有burpsuite Pro，那么生成CSRF POC会很容易，或者如果你没有办法，也可以有替代方案
1.Burpsuite Pro{Engagement->Generate CSRF PoC}
单击"Generate CSRF PoC",生成HTML表单
在这里，您可以通过在浏览器选项中进行测试来直接进行测试，或者将其复制并粘贴到本地文件中并将其保存在CSRF.html中
现在在浏览器中打开它并单击提交请求
现在，如果电子邮件ID发生变化，那么恭喜您已在该应用程序上发现了第一个CSRF漏洞
2.如果没有Burpsuite专业版的替代方法
使用此网站：https://csrf.infos3c.net/
在这个网站上，您需要复制并粘贴该网站上的消息正文，您将获得POC（使用风险自负）
或者直接使用下面的HTML表单
<html><body><script>history.pushState('', '', '/')</script><form action="URL" method="POST"><input type="hidden" name="email" value="[email protected]" /><input type="submit" value="Submit request" /></form></body></html>
在这种形式下，您需要手动添加输入，但最好使用 POC 网站
3. 解决这个实验室问题
为了解决这个实验，有一个漏洞利用服务器，因此请转到漏洞利用服务器并将CSRF HTML表单粘贴到正文上
<html><!-- CSRF PoC - generated by Burp Suite Professional --><body><script>history.pushState('', '', '/')</script><form action="https://0a8800fd03f47b4580bab77.web-security-academy.net/my-account/change-email" method="POST"><input type="hidden" name="email" value="[email protected]" /><input type="hidden" value="Submit request" /></form><script>document.forms[0].submit();</script></body></html>
然后我们会添加一些javascript
<script>document.forms[0].submit();</script>
这有助于自动重定向，对于bug奖励不是必须的
您只需在应用程序中显示更改即可
初学者提示：首先，注意所有状态更改请求，并使用firefox不要使用Chrome来测试CSRF bug
CSRF的通用保护：
- CSRF token— CSRF token是由服务器端应用程序生成并与客户端共享的唯一且不可预测的值。当尝试执行敏感操作（例如提交表单）时，客户端必须在请求中包含正确的CSRF token。这使得攻击者很难代表受害者构建有效的请求。
- SameSite cookie — SameSite 是一种浏览器安全机制，用于确定何时将网站的cookie包含在源自其他网站的请求中。由于执行敏感操作的请求通常需要经过身份验证的会话cookie，因此适当的SameSite限制可能会阻止攻击者跨站点触发这些操作。自2021年起，ChromeLax默认强制实施SameSite限制。由于这是提议的标准，我们预计其他主要浏览器将来也会采用这种行为。
- 基于Referer的验证— 某些应用程序利用HTTP Referer标头来尝试防御CSRF攻击，通常是通过验证请求是否源自应用程序自己的域。这通常不如CSRF token验证有效。
# 绕过
## 什么是CSRF token？
CSRF token只不过是服务器端应用程序生成的唯一密钥，并与客户端共享以防止CSRF攻击
如果客户端没有正确提供CSRF令牌，服务端会拒绝当前请求
CSRF_Token=80FassfjkddmmOhi9M9wyna8tadnsaak3ODOR8d6u
如果实现正确，它将防止CSRF攻击，但如果不正确，可以使用一些技术绕过它，所以让我们讨论一下
## CSRF token的验证请求方法
一些应用程序根据请求验证token，如果POST请求是有效的，把请求修改为GET则无效，这是很多应用程序中的常见缺陷之一
因此，首先前往实验室并使用凭据注册，然后就可以看到更改电子邮件ID功能
因此，更新电子邮件ID并捕获该请求，然后发送到repeater
然后将burpsuite中的请求方式从POST修改为GET
使用CSRF POC生成器，可以构造poc
接下来，删除CSRF token
您需要实时在浏览器上加载此 HTML 文件以获取报告，但对于此挑战，有一个漏洞利用服务器，因此打开该服务器并将其粘贴到正文部分
下一个利用并向受害者提供服务的商店
现在解决了
## CSRF token验证取决于token的存在
在此实验中，应用程序具有正确的CSRF token，但当用户删除token时就不会验证
在这里可以看到CSRF token，只需要删除该token就可以了
然后使用CSRF POC 生成器构造CSRF POC，并复制到漏洞利用服务器上
现在存储该漏洞并将该漏洞发送给受害者
现在解决了
## CSRF token不与用户会话进行绑定
在本实验中，提供两个账户绕过CSRF保护，但这里只能使用一次CSRF token，并不接受相同的电子邮件ID
首先在普通窗口登录一个账号
隐身窗口登录另一个账号
在任何账号中更新电子邮件并使用CSRF token捕获请求
然后,使用Burp生成CSRF POC并复制到本地文件中
使用登录另一个账号的隐身窗口打开。可以发现电子邮件ID发生变化
可以确认存在CSRF漏洞
因此，为了解决这个问题，实验室将有效负载复制并粘贴到漏洞利用服务器中，并将漏洞利用程序存储并传递给受害者
注意：您需要使用尚未使用的新 CSRF 令牌和邮件 ID（如果需要再次执行此过程）
现在已经解决了
# 总结
如果请求中存在CSRF token，也可以尝试绕过：
1. 修改请求方式，如POST修改为GET
2. 直接删除CSRF token字段
3. 使用其他登录用户的CSRF
---
# LINKS
1.CSRF（跨站请求伪造）解释
https://infosecwriteups.com/explanation-of-csrf-cross-site-request-forgery-bc6a5042bcbf
2.揭露基本的CSRF漏洞：初学者的猎人指南
https://infosecwriteups.com/unmasking-basic-csrf-bug-hunter-5003dbe44466
3.黑客CSRF：绕过CSRF token
https://infosecwriteups.com/hacking-csrf-bypassing-of-csrf-token-f03b51c36d31
#END#
原文始发于微信公众号（一盅清茶）：漏洞学习|CSRF跨站请求伪造
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论