CSRF (Cross Site Request Forgery)
加入HackenProof Discord服务器，与经验丰富的黑客和赏金猎人交流！
黑客见解 参与深入探讨黑客的刺激和挑战的内容
实时黑客新闻 通过实时新闻和见解及时了解快节奏的黑客世界
最新公告 随时了解最新的赏金任务发布和重要平台更新
加入我们的 Discord 并开始与顶尖黑客合作！
解释跨站请求伪造（CSRF）
**跨站请求伪造（CSRF）**是一种在Web应用程序中发现的安全漏洞类型。它使攻击者能够利用受害者的已验证会话，代表毫不知情的用户执行操作。当已登录受害者平台的用户访问恶意站点时，攻击就会执行。该站点随后通过执行JavaScript、提交表单或获取图像等方法触发对受害者帐户的请求。
CSRF攻击的先决条件
要利用CSRF漏洞，必须满足几个条件：
识别有价值的操作：攻击者需要找到值得利用的操作，例如更改用户的密码、电子邮件或提升权限。
会话管理：用户的会话应仅通过Cookie或HTTP基本身份验证标头管理，因为其他标头无法用于此目的进行操作。
无法预测的参数：请求不应包含无法预测的参数，因为这些参数可能会阻止攻击。
快速检查
您可以在Burp中捕获请求并检查CSRF保护，并且可以单击复制为fetch以从浏览器中进行测试请求：
防御CSRF攻击
可以实施多种对策来防范CSRF攻击：
SameSite cookies：此属性可防止浏览器随跨站请求发送Cookie。了解更多关于SameSite cookies的信息。
跨域资源共享：受害站点的CORS策略可能影响攻击的可行性，特别是如果攻击需要读取受害站点的响应。了解有关CORS绕过的信息。
用户验证：提示用户输入密码或解决验证码可以确认用户的意图。
检查引用者或来源标头：验证这些标头可以帮助确保请求来自受信任的来源。但是，精心构造的URL可能会绕过实施不良的检查，例如：
使用
http://mal.net?orig=http://example.com（URL以受信任的URL结尾）使用
http://example.com.mal.net（URL以受信任的URL开头）
修改参数名称：更改POST或GET请求中的参数名称可以帮助防止自动化攻击。
CSRF令牌：在每个会话中加入唯一的CSRF令牌，并要求在后续请求中使用此令牌，可以显著减轻CSRF的风险。通过强制执行CORS可以增强令牌的有效性。
理解并实施这些防御措施对于维护Web应用程序的安全性和完整性至关重要。
防御绕过
从POST到GET
也许您想要滥用的表单准备发送带有CSRF令牌的POST请求，但是，您应该检查是否GET也是有效的，以及当您发送GET请求时CSRF令牌是否仍在验证。
缺少令牌
应用程序可能会实施一种机制，在出现令牌时验证令牌。但是，如果在令牌缺失时完全跳过验证，则会出现漏洞。攻击者可以通过删除携带令牌的参数（而不仅仅是其值）来利用这一点。这使他们可以规避验证过程并有效地执行跨站请求伪造（CSRF）攻击。
CSRF令牌未绑定到用户会话
未将CSRF令牌绑定到用户会话的应用程序存在重大安全风险。这些系统会对全局池中的令牌进行验证，而不是确保每个令牌都绑定到发起会话。
以下是攻击者如何利用这一点的方法：
使用自己的帐户进行身份验证。
从全局池中获取有效的CSRF令牌。
使用此令牌对受害者进行CSRF攻击。
此漏洞允许攻击者代表受害者进行未经授权的请求，利用应用程序的不足的令牌验证机制。
方法绕过
如果请求使用了“奇怪”的方法，请检查方法****覆盖功能是否有效。例如，如果使用PUT方法，您可以尝试使用POST方法并发送：https://example.com/my/dear/api/val/num?_method=PUT
这也可以通过在POST请求中发送**_method参数或使用以下标头**来实现：
X-HTTP-Method
X-HTTP-Method-Override
X-Method-Override
自定义标头令牌绕过
如果请求在请求中添加了一个带有令牌的自定义标头作为CSRF保护方法，那么：
在没有自定义令牌和标头的情况下测试请求。
使用完全相同长度但不同令牌测试请求。
通过Cookie验证CSRF令牌
应用程序可能通过在Cookie和请求参数中复制令牌或通过设置CSRF Cookie并验证后端发送的令牌来实现CSRF保护。应用程序通过检查请求参数中的令牌是否与Cookie中的值对齐来验证请求。
但是，如果网站存在漏洞，允许攻击者在受害者的浏览器中设置CSRF Cookie，例如CRLF漏洞，那么此方法容易受到CSRF攻击。攻击者可以通过加载设置Cookie的欺骗性图像，然后发起CSRF攻击来利用这一点。
以下是攻击可能构建的示例：
Content-Type 更改
根据此链接，为了避免预检请求使用 POST 方法，这些是允许的 Content-Type 值：
application/x-www-form-urlencodedmultipart/form-datatext/plain
但是，请注意，服务器逻辑可能会有所不同取决于使用的 Content-Type，因此您应该尝试提到的值和其他值，如 application/json，text/xml，application/xml。
示例（来自此处）将 JSON 数据发送为 text/plain：
绕过预检请求以获取JSON数据
在尝试通过POST请求发送JSON数据时，在HTML表单中使用 Content-Type: application/json 是不直接可能的。同样，利用 XMLHttpRequest 发送此内容类型会启动一个预检请求。尽管如此，仍然有策略可以潜在地绕过这种限制，并检查服务器是否处理JSON数据，而不考虑Content-Type：
使用替代内容类型：通过在表单中设置
enctype="text/plain"，使用Content-Type: text/plain或Content-Type: application/x-www-form-urlencoded。这种方法测试后端是否使用数据，而不考虑Content-Type。修改内容类型：为了避免预检请求，同时确保服务器将内容识别为JSON，您可以使用
Content-Type: text/plain; application/json发送数据。这不会触发预检请求，但如果服务器配置为接受application/json，则可能会被正确处理。SWF Flash文件利用：一种较不常见但可行的方法涉及使用SWF Flash文件来绕过此类限制。要深入了解此技术，请参考此文章。
绕过引用者/来源检查
避免引用者标头
应用程序可能仅在存在时验证 'Referer' 标头。为了防止浏览器发送此标头，可以使用以下HTML meta标记：
这会确保省略“Referer”标头，可能绕过某些应用程序中的验证检查。
正则表达式绕过
URL Format Bypass要在URL中设置服务器的域名，以便Referrer将其发送到参数中，您可以执行：
HEAD方法绕过
这篇CTF解密的第一部分解释了Oak的源代码，一个路由器被设置为将HEAD请求处理为GET请求，且不返回响应主体 - 这是一个常见的解决方法，不仅仅适用于Oak。与处理HEAD请求的特定处理程序不同，它们只是交给GET处理程序，但应用程序会删除响应主体。
因此，如果GET请求受限，您可以发送一个将被处理为GET请求的HEAD请求。
利用示例
窃取CSRF令牌
如果正在使用CSRF令牌作为防御，您可以尝试通过XSS漏洞或悬挂标记漏洞窃取它。
使用HTML标签进行GET
其他可以用来自动发送GET请求的HTML5标签有：
表单 GET 请求
表单POST请求
通过iframe进行表单POST请求
Ajax POST 请求
multipart/form-data POST 请求
multipart/form-data POST 请求 v2
从iframe内部发起表单POST请求
窃取 CSRF 令牌并发送 POST 请求
窃取 CSRF 令牌并使用 iframe、表单和 Ajax 发送 Post 请求
窃取 CSRF 令牌并使用 iframe 和表单发送 POST 请求
窃取令牌并使用2个iframe发送
使用Ajax窃取CSRF令牌并使用表单发送POST请求
使用 Socket.IO 进行 CSRF
CSRF登录暴力破解
该代码可用于使用CSRF令牌对登录表单进行暴力破解（还使用了头部X-Forwarded-For尝试绕过可能的IP黑名单）：
工具
参考资料
加入 HackenProof Discord 服务器，与经验丰富的黑客和赏金猎人交流！
黑客见解 参与深入探讨黑客行为的刺激和挑战的内容
实时黑客新闻 通过实时新闻和见解了解快节奏的黑客世界
最新公告 了解最新的赏金计划发布和重要平台更新
加入我们的 Discord，立即与顶尖黑客合作！
最后更新于