csrf漏洞详解

Yf3_te

于 2024-03-01 09:59:25 发布

阅读量949

点赞数 16

文章标签： csrf 安全 web安全

本文链接：https://blog.csdn.net/2301_80661529/article/details/136383899

版权

csrf漏洞概述

跨站请求伪造（Cross-Site Request Forgery，简称CSRF或XSRF）是一种常见的web应用安全漏洞，它允许攻击者利用用户的已验证身份发起恶意请求而不被用户察觉。这种攻击手段主要利用的是用户已登录的身份凭证（如session cookie）在无意识的状态下自动携带到攻击者构造的请求中。

漏洞原理

当用户登录一个网站后，该网站会为用户生成一个会话标识（session token），通常存储在cookie中，用于验证后续请求的合法性。

CSRF攻击者通过构建一个恶意网页或邮件中的链接，其中包含了对目标网站的请求（如转账、删除账户等敏感操作）。

用户在不知情的情况下访问了这个恶意网页或点击了邮件中的链接，浏览器会自动带上用户的session cookie向目标网站发起请求。

目标网站收到请求后，由于请求中携带有有效的session token，服务器误以为这是用户的真实意图，进而执行了请求中的恶意操作。

漏洞危害

跨站请求伪造（CSRF）漏洞的危害主要包括但不限于以下几个方面：

账户操作篡改：
攻击者可以假冒用户身份执行高权限操作，例如：转账、更改密码、删除账户、购买商品等，造成用户的财产损失或个人信息泄露。

个人隐私泄露：
如果网站中有涉及个人隐私的功能接口存在CSRF漏洞，攻击者可能借此窃取用户的私人数据，如联系人列表、聊天记录、财务信息等。

账户劫持：
利用CSRF漏洞更改用户的账户设置，包括电子邮件地址、密保问题答案等，为进一步接管账户奠定基础。

社交网络蠕虫传播：
如前面提到的案例，如果社交网络平台的部分接口存在CSRF漏洞，攻击者可以制作CSRF蠕虫，通过链式反应迅速扩大攻击范围，例如：自动向用户的好友发送包含恶意链接的消息。

系统级攻击：
对于企业级应用或者物联网设备，CSRF漏洞可能导致系统级控制命令的非法执行，如改变路由器配置、控制系统设备行为等。

组合攻击：
CSRF攻击可以与其他漏洞结合，形成组合拳，比如与XSS（跨站脚本攻击）结合，进一步提升攻击成功率和复杂度。

csrf与xss漏洞的区别

原理上：

csrf：攻击者利用用户的已登录状态，在用户不知情的情况下，诱导用户浏览器向目标网站发送非用户本意的请求，通常是通过GET或POST请求执行操作（如转账、删除账户等）。

xss：攻击者向目标网站注入恶意脚本，这些脚本在用户浏览器中被执行，从而达到获取用户敏感信息、控制用户浏览器行为的目的。

危害上：

csrf：导致用户账号内的资产损失或数据变更，而用户并未主动发起这样的操作。

xss：可以盗取用户的会话信息（如session cookie）、操纵网页内容、进行钓鱼攻击等。

关键点：

csrf：不涉及代码注入，而是利用了用户的认证凭据（如cookie）在用户浏览器中被自动附带在请求头上这一机制。

xss：主要是通过注入JavaScript等客户端脚本，绕过安全过滤机制，让浏览器误认为这些脚本是合法内容的一部分。

预防方法上：

csrf：使用一次性令牌（CSRF token）、双重验证、检查Referer头（但不够可靠）等方式确保请求来自于可信源。

xss：对用户输入进行严格的净化和转义、使用HTTP-only cookie防止通过JavaScript读取、启用CSP（Content Security Policy）等策略。

常见payload

在跨站请求伪造（CSRF）攻击中，Payload通常指的并不是传统意义上的exploit payload，而是指攻击者构造的恶意HTML表单、图片标签（image tags）、XMLHttpRequests等，这些内容会诱导用户的浏览器发送未经用户授权的HTTP请求到目标网站。以下是一些典型的CSRF Payload示例：

1.隐藏表单提交：
<form action="https://targetsite.com/transfer" method="POST">
    <input type="hidden" name="to_account" value="attacker_account">
    <input type="hidden" name="amount" value="100000">
    <input type="submit" style="display:none;">
</form>
<script>document.forms[0].submit();</script>
用户访问包含此Payload的页面时，表单会被自动提交，将资金转移到攻击者指定的账户。

2.图片标签（IMG SRC）：
<img src="https://targetsite.com/api/deleteAccount?accountID=123&confirmToken=abc" />
浏览器加载图片时实际上会发送一个GET请求。如果目标API没有对CSRF进行防护，则可能触发账户删除操作。

3.XMLHttpRequest或Fetch API调用：
fetch('https://targetsite.com/changePassword', {
    method: 'POST',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded'
    },
    body: 'oldPass=current&newPass=hacked'
});
JavaScript代码可以在用户访问包含它的页面时，悄悄发起一个更改密码的请求。

4.iframe嵌入：
<iframe src="https://targetsite.com/performAction?param1=value1&param2=value2"></iframe>
将目标URL嵌入到隐藏的iframe中，当页面加载时，浏览器会尝试加载iframe中的资源，间接触发请求。

防范CSRF的方法往往不是针对Payload本身，而是通过在目标站点增加额外的验证机制，例如使用CSRF Tokens，确保请求是由合法用户在知情情况下发起的。

CSRF防护绕过（Bypass）

针对CSRF的两种防御分别有bypass手段：

1）Referer绕过

空referer绕过：其他协议（data：）或https跳http
包含referer：若只检查是否包含网址，只需在我们的网站上创建一个文件/文件夹即可，如 https://www.yoursite.com/https://www.theirsite.com/

2）CSRF-token绕过：

删除令牌：删除cookie/参数中token，免服务器验证
令牌共享：创建两个帐户，替换token看是否可以互相共用；
篡改令牌值：有时系统只会检查CSRF令牌的长度；
解码CSRF令牌：尝试进行MD5或Base64编码
修改请求方法：post改为get
窃取token：重定向、XSS、web缓存欺骗、clickjacking等都可能导致token泄露

csrf挖掘和自动化工具

zaproxy安装

zaproxy(OWASP Zed Attack Proxy)是一款功能强大的开源Web应用安全测试工具。

kali安装zaproxy

1.更新软件包列表

sudo apt update

2.安装zaproxy

sudo apt install zaproxy

3.zaproxy使用

zaproxy

zaproxy配置

初次打开ZAP时，会看到以下对话框，询问是否要保持ZAP进程。

保存进程则可以让你的操作得到保留，下次只要打开历史进程就可以取到之前扫描过的站点以及测试结果等。

一般来说，如果对固定的产品做定期扫描，应该保存一个进程做为长期使用，选第一或者第二个选项都可以。

如果只是想先简单尝试ZAP功能，可以选择第三个选项，那么当前进程暂时不会被保存。

配置代理：点击设置

设置代理为localhost，端口号为8080（浏览器的端口），同时浏览器使用手动配置代理

完成这一设置以后，我们再用这个浏览器去访问站点时，都会通过ZAP这个中间人，于是这就给ZAP提供了抓包、分析、渗透测试的可能性。

挖掘步骤

填入要挖掘的URL，点击下图的工具即可

但是传统爬虫可能并没有什么效果，这里补充一下Ajax爬虫

Ajax爬虫是一种网络爬虫技术，主要用于抓取网页中通过异步JavaScript和XML（AJAX）技术动态加载的数据。传统的网络爬虫通常只能获取静态HTML页面上的内容，但许多现代网站为了提高用户体验，采用了AJAX技术，即页面在用户交互或页面滚动时动态从服务器加载新的内容，而不是一次性全部加载到页面上。

在快速攻击过程中，ZAP做了以下几件事：

使用爬虫抓取被测站点的所有页面
在页面抓取的过程中被动扫描所有获得的页面
抓取完毕后用主动扫描的方式分析页面，功能和参数

防护措施

添加CSRF Token：服务器在渲染表单页面时生成一个随机的、一次性的token，随表单一起提交给服务器；服务器在处理请求时验证这个token是否有效。
双重验证：除了session验证之外，还可以要求关键操作需经过双重验证，如短信验证码、二次确认等。
验证Referer头：检查HTTP Referer头部，判断请求是否来自同一域名下的页面。但这不是一种可靠的防御机制，因为某些情况下Referer信息可能不可靠或被禁用。