本次课程是 Web 安全漏洞学习的延续，系统讲解CSRF 跨站请求伪造漏洞，从定义、原理、攻击条件、测试流程、分类利用、实操案例、防御手段全维度拆解，同时明确 CSRF 与 XSS 的核心区别，以下是分模块的详细总结，包含所有实操步骤、核心思路和必备知识点。

1 CSRF 跨站请求伪造基础认知（定义 + 核心区别 + 必备知识点）

1.1 核心定义

全称：跨站请求伪造，简称 CSRF（课程中笔误写为 CSF/XSF，均指同一漏洞）；
别称：One click attack（一键式攻击），因攻击者只需诱骗用户点击一次恶意链接即可完成攻击；
本质：挟持已登录 web 应用的用户，在其合法权限下执行非本意的操作，攻击者无需盗取用户账号、密码等信息，仅借用用户的登录状态。

条件：

后台为登录状态
数据包添加的格式

1.2 CSRF 与 XSS 的核心区别

二者均需向用户发送恶意链接诱使其点击，但权限获取方式、操作主体、攻击逻辑完全不同，是 Web 安全中极易混淆的两个漏洞，核心对比如下表：

表格

对比维度	CSRF 跨站请求伪造	XSS 跨站脚本攻击
核心逻辑	借用用户已登录的合法权限执行操作	xxxxxxxxxx <?php $conn = mysqli_connect(‘127.0.0.1’,’root’,’test’); $res = mysqli_query($conn,”select id from users where username=’”$_GET[‘username’].”‘“); $row = mysqli_fetch_array($res) php>php
权限获取方式	不盗取任何用户信息，依赖用户的登录状态	通过脚本注入盗取用户敏感信息（Cookie / 键盘记录）
攻击操作主体	用户自身在登录状态下执行伪造请求	攻击者伪造用户身份后自主执行操作
核心前提	目标网站对敏感操作的请求易被伪造+ 用户未登出	目标网站存在 XSS 注入点（存储型 / 反射型 / DOM 型）
攻击目的	以用户名义执行操作（改信息、转账、改密码）	盗取用户信息，或通过盗取的信息进一步操作

1.3 CSRF 的主要危害

攻击者可利用用户的登录状态，以用户名义执行以下操作，所有操作均基于用户的现有权限：

基础操作：发邮件、发消息、修改个人信息（姓名、手机号、地址、邮箱）；
高危操作：修改账号密码、进行资金转账、购买商品、删除数据等。

1.4 必备知识点

Cookie/Session：Web 应用中用于保存用户登录状态的凭证，Cookie 存储在客户端浏览器，Session 存储在服务器，二者是 CSRF 攻击的核心依托（无有效凭证则无法完成 CSRF 攻击）；
身份验证：Web 应用验证用户身份的方式，CSRF 利用的是简单身份验证的缺陷（仅验证凭证是否有效，不验证请求是否为用户自愿发出）；
GET/POST 传参：HTTP 请求的两种基本传参方式，GET 参数暴露在 URL 中，POST 参数放在请求体中，二者决定了 CSRF 的不同攻击方式。

2 CSRF 攻击核心原理

2.1 攻击核心成因

Web 应用的简单身份验证机制存在致命缺陷：仅能验证请求是否来自持有有效 Cookie/Session 的用户浏览器，但无法验证该请求是否是用户自愿发出的。

2.2 攻击成功的两个必要条件

条件 1：目标网站对敏感操作（增删改） 的请求 极易被伪造
- 表现：修改信息 / 密码 / 转账时，无二次验证（原密码、验证码、短信验证）、无 Token 验证、直接通过 GET/POST 提交参数即可执行操作；
- 核心：网站未对请求的合法性、真实性做校验，攻击者可轻易模仿正常请求的参数和格式。
条件 2：用户已登录目标网站（持有有效 Cookie/Session）且未登出的情况下，点击了攻击者发送的恶意链接 / 访问了恶意网站
- 关键：Cookie/Session 未失效，浏览器会在发送请求时自动携带该凭证，服务器据此判定为合法用户操作。

2.3 攻击的三方主体

用户浏览器（C）：持有目标网站的有效登录凭证（Cookie/Session），是请求的发送者；
受信任的漏洞网站（A）：存在 CSRF 漏洞的目标网站，用户已登录并信任该网站，是请求的处理者；
攻击者的恶意网站（B）：存放恶意链接 / 伪造表单的网站，是攻击的发起者。

2.4 完整攻击流程

用户登录漏洞网站：用户在浏览器中访问网站 A，输入账号密码完成登录，服务器验证后生成有效 Cookie/Session并返回至用户浏览器保存；
用户未登出且访问恶意链接：用户未关闭网站 A、未执行登出操作（凭证仍有效），此时点击攻击者发送的来自网站 B 的恶意链接 / 访问网站 B；
恶意链接触发伪造请求：网站 B 的恶意链接会构造一个模仿网站 A 正常操作的伪造请求（如修改信息、转账），并发送至网站 A；
浏览器自动携带凭证：用户浏览器在发送该请求时，会自动携带网站 A 的有效 Cookie/Session（浏览器的同源策略特性）；
服务器验证凭证并执行操作：网站 A 仅验证 Cookie/Session 的有效性，确认是合法用户后，直接执行伪造请求，攻击者完成攻击；
用户发现非本意操作：用户在网站 A 中发现自己的信息被修改、资金被转账等，且全程未主动执行该操作。

2.5 必备知识点

浏览器同源策略：浏览器的安全机制，规定不同域名的网站之间不能随意访问彼此的资源，但会在发送请求时自动携带目标域名的 Cookie，这是 CSRF 攻击的关键技术基础；
302 重定向：HTTP 状态码，代表临时重定向，CSRF 攻击中部分请求会触发 302 重定向，需通过抓包工具的follow redirect功能跟踪请求流程；
200 状态码：HTTP 状态码，代表请求成功执行，是判断攻击是否成功的重要依据。

3 CSRF 漏洞的测试流程

测试的核心目标：判断目标网站是否存在被 CSRF 攻击的可能性，需对网站的敏感操作逐一测试，以下是完整实操步骤和判断思路：

3.1 标记目标网站的敏感操作点

重点标记网站中涉及用户信息、资金、权限的增删改操作，包括但不限于：

修改个人信息（姓名、手机号、地址、邮箱）；
修改账号密码（含找回密码、修改支付密码）；
资金操作（转账、充值、消费、提现）；
数据操作（发布内容、删除内容、修改权限、添加好友）。

3.2 模拟正常操作，观察业务逻辑，判断请求是否易被伪造

实操动作：使用抓包工具（如 Burp Suite）抓取该敏感操作的 HTTP 请求，分析传参方式（GET/POST）、参数格式、请求地址；
核心判断标准（满足任意一条，即判定为请求易被伪造）：
- 操作时无任何二次验证：无需输入原密码、验证码、短信验证码，点击即可执行；
- 传参方式简单：直接通过 GET 传参（参数暴露在 URL 中），或 POST 传参无任何加密 / 验证；
- 服务器仅验证 Cookie/Session，未对请求的来源、真实性做校验；
- 操作的请求参数固定且可预测：无随机生成的验证字符（如 Token）。

3.2.1.1 检查Cookie/Session 的有效期，判断攻击成功概率

实操动作：在浏览器中查看目标网站的 Cookie 信息（F12→Application→Cookies），查看创建时间、过期时间、最后访问时间；
核心判断标准：
- 有效期越长，攻击成功概率越高（如创建于 1 月 13 日的 Cookie，至测试时仍有效，危害极大）；
- 无操作超时机制（如 10 分钟无操作仍不自动登出），攻击成功概率越高；
- Session/Cookie 若为临时有效（关闭浏览器即失效），攻击成功概率大幅降低。

3.3 测试结论

同时满足以下两点，即可判定目标网站存在 CSRF 漏洞：

敏感操作的请求易被伪造；
Cookie/Session有效期较长，且无严格的超时登出机制。

3.4 必备知识点

抓包工具（Burp Suite）：Web 安全测试的核心工具，可抓取、修改、重放 HTTP 请求，核心功能：
- Repeater 模块：重放请求，用于测试请求是否可被伪造、修改参数后是否仍能执行；
- Follow Redirect：跟踪 302 重定向请求，查看重定向后的请求执行结果；
Cookie 查看方法：浏览器 F12 开发者工具→Application→Cookies，可查看目标网站的所有 Cookie 信息（名称、值、域名、过期时间）；
增删改操作：Web 应用中最易存在 CSRF 漏洞的操作，因查询操作（GET）一般无危害，而增删改会直接改变用户数据 / 状态。

4 CSRF 漏洞的分类与利用

根据目标网站敏感操作的传参方式，CSRF 分为GET 型和POST 型，二者的攻击方式不同，但核心思路均为伪造与正常请求一致的参数和格式，诱骗用户执行，课程结合修改个人信息、修改密码、转账钓鱼3 个实操案例讲解，以下是分类型的详细实操步骤。

4.1 （一）GET 型 CSRF

4.1.1 核心特点

敏感操作通过GET 传参实现，参数直接暴露在 URL 中，攻击者只需修改 URL 中的参数，即可伪造恶意链接。

4.1.2 实操步骤

抓包分析正常请求：丽丽登录购物网站，执行修改个人信息操作，攻击者用 Burp Suite 抓取该请求，发现为 GET 传参，URL 格式为：目标网站IP/修改页面?性别=女&手机号=123456&地址=北京朝阳区&邮箱=lili@xxx.com；
伪造恶意 URL：攻击者修改 URL 中的敏感参数（如手机号改为黑客自己的、地址改为北京丰台区），并对参数做URL 编码（降低伪造痕迹，避免用户发现参数异常）；
诱骗用户点击：攻击者将伪造的恶意 URL 发送给已登录且未登出的丽丽，以 “获奖验证”“信息核对” 等理由诱使其点击；
攻击成功：丽丽点击链接后，浏览器自动携带购物网站的 Cookie 发送请求，服务器验证凭证后执行操作，丽丽的个人信息被篡改。

4.1.2.1 核心思路

GET 型 CSRF 的核心是URL 伪造，利用 GET 传参 “参数在 URL 中” 的特点，直接修改参数即可完成请求伪造，无需复杂操作。

4.2 （二）POST 型 CSRF

4.2.1 核心特点

敏感操作通过POST 传参实现，参数放在请求体中，无法直接通过 URL 伪造，需伪造自动提交的隐藏表单，诱骗用户访问表单页面。

4.2.2 实操步骤（以修改皮卡丘靶场个人信息为例）

抓包分析正常请求：登录皮卡丘靶场的 CSRF-POST 模块，执行修改个人信息操作，抓包发现为 POST 传参，参数在请求体中，请求地址为127.0.0.1/pikachu/csrf/csrf_post_edit.php；
伪造隐藏的自动提交表单：
- 用JS/HTML编写表单，表单的action属性设为目标网站的修改页面地址，method属性设为 POST；
- 在表单中创建input标签，设置为隐藏属性（hidden），参数值改为攻击者目标（如地址 = 银川、手机号 = 112233）；
- 添加自动提交代码（如form.submit()），让用户访问页面时无需操作，表单自动提交；
- 将表单保存为post.html，部署在攻击者后台（本地 / 公网）；
诱骗用户访问：将攻击者后台的post.html链接发送给已登录且未登出的受害者，诱使其点击；
攻击成功：受害者点击链接后，页面自动提交伪造的 POST 请求，浏览器携带有效 Cookie，服务器执行操作，受害者信息被篡改。

4.2.3 核心思路

POST 型 CSRF 的核心是表单伪造，借用 XSS 的攻击思路，通过隐藏表单 + 自动提交，模拟正常的 POST 请求，绕开 “参数在请求体中” 的限制。

4.3 CSRF 经典实操案例（3 个高危场景，含核心漏洞点）

课程结合修改个人信息、修改 DVWA 密码、转账系统钓鱼3 个场景演示攻击，均为实际开发中高频出现的 CSRF 漏洞场景，核心漏洞点和攻击思路如下：

4.3.1 案例 1：修改购物网站个人信息（GET 型）

核心漏洞点：修改信息时无任何验证，直接 GET 传参，Cookie 有效期长；
攻击关键：伪造 URL 并做 URL 编码，诱骗已登录用户点击。

4.3.2 案例 2：修改 DVWA 靶场密码（GET/POST 均可）

核心漏洞点：修改密码时无需验证原密码，直接提交新密码即可，且支持 GET 传参；
攻击关键：伪造含新密码参数的 URL / 隐藏表单，用户点击后密码被直接篡改，原密码无法登录。

4.3.3 案例 3：转账系统钓鱼（POST 型，高危）

课程设计了简易转账系统，含小明、小红、小黑三个用户，小黑为攻击者，核心分两种钓鱼方式，均为实际金融场景中典型的 CSRF 攻击：

方式 1：伪造假转账页面，偷梁换柱
- 伪造与正常转账页面完全一致的表单，让用户输入转账人、收款人、金额；
- 故意让用户输入的收款人参数无 name 属性（无法提交），同时在表单中添加隐藏的收款人参数（值为黑客小黑的卡号 / 姓名）；
- 用户输入信息并点击转账后，实际提交的是隐藏的黑客参数，资金被转给小黑。
方式 2：全隐藏自动提交表单，一键转账
- 直接伪造含转账人（小明）、收款人（小黑）、固定金额的隐藏表单，添加自动提交代码；
- 将表单链接发送给已登录的小明，小明点击链接后无需任何操作，资金直接转给小黑，全程无感知。

核心漏洞点：转账时无任何二次验证（密码、验证码、短信验证），直接 POST 传参即可执行，无 Token 验证。

4.4 必备知识点

URL 编码：将特殊字符（如空格、中文）转换为 %+ 十六进制的形式，用于隐藏 GET 型 CSRF 的参数痕迹，避免用户发现 URL 异常；
隐藏表单（hidden）：将 form/input 标签设为type="hidden"，用户访问页面时无法看到表单，仅能看到攻击者设置的文字 / 图片，提升攻击隐蔽性；
自动提交代码：如document.getElementById("form").submit()，页面加载时自动执行表单提交，无需用户手动点击，是 POST 型 CSRF 的核心；
表单的 name 属性：HTTP 请求中，只有带 name 属性的 input 参数才会被提交，攻击者可利用此特性做 “偷梁换柱”（如案例 3 的钓鱼方式 1）。

5 CSRF 漏洞的防御手段（核心方案 + 实操思路 + 必备知识点）

方法：

看验证来源
看凭证有无token
看关键操作有无验证

CSRF 的防御核心是让伪造的请求无法被服务器执行，从服务器端验证、会话管理、操作规范、用户端防护四个维度入手，课程讲解了核心防御方案和辅助防御手段，其中Token 验证是最有效、最常用的核心方案。

5.1 （一）核心防御方案 1：随机一次性 Token 验证（最核心，必实现）

5.1.1 核心原理

为每个用户的每次敏感请求生成一个唯一、随机、一次生效的 Token（令牌），Token 随请求一起提交，服务器同时验证Cookie/Session和Token，二者均有效且匹配时，才执行请求。

5.1.2 实操实现步骤

生成 Token：服务器在用户加载敏感操作页面时（如修改信息、转账），基于当前微秒时间 + 随机前缀 / 后缀生成唯一 Token（微秒时间保证不重复，随机前缀提升复杂度）；
前端隐藏传输：将 Token 以隐藏 input 标签的形式嵌入表单 / URL 中，用户无法看到，如<input type="hidden" name="token" value="随机字符串">；
请求携带 Token：用户执行操作时，请求会同时携带 Cookie/Session 和 Token，GET 型放在 URL 中，POST 型放在请求体中；
服务器双重验证：服务器接收到请求后，同时验证 Cookie/Session（用户身份）和 Token（请求真实性）：
- 若二者均有效且匹配，执行请求；
- 若 Token 不存在、不匹配、已失效，拒绝执行请求；
Token 一次生效：服务器验证成功后，立即将该 Token 标记为失效，同一 Token 无法再次使用，且用户每次刷新页面 / 重新操作，都会生成新的 Token。

5.1.3 防御关键

Token 的随机性和一次性，攻击者无法提前伪造与用户请求一致的 Token，即使伪造了参数，因 Token 不匹配，服务器会直接拒绝请求。

5.2 （二）核心防御方案 2：Referer 来源验证

5.2.1 核心原理

验证 HTTP 请求头中的Referer 字段（该字段记录了请求的来源页面地址），服务器仅接受来自本站的请求，拒绝来自外部网站的请求。

5.2.2 实操实现思路

服务器在处理敏感请求时，获取请求头中的 Referer 字段；
判断 Referer 字段是否为目标网站的域名（如www.xxx.com）；
若为本站域名，执行请求；若为外部域名 / 无 Referer 字段，拒绝执行。

5.2.3 注意点

Referer 验证可作为辅助防御手段，不可单独使用，因 Referer 字段可被部分工具修改 / 伪造，且部分浏览器会因安全策略屏蔽 Referer 字段。

5.3 （三）辅助防御手段（服务器端 + 用户端，多维度防护）

5.3.1 维度 1：服务器端 - 安全的会话管理

设置短时间的会话超时机制：如 5/10 分钟无操作，自动登出用户，销毁 Cookie/Session，避免凭证长期有效；
关闭浏览器即销毁 Session：将 Session 设置为临时有效，用户关闭浏览器后，Session 立即失效，降低凭证被利用的概率；
不允许浏览器保存敏感 Cookie：设置 Cookie 的HttpOnly和Secure属性：
- HttpOnly：禁止 JS 读取 Cookie，防止 Cookie 被 XSS 脚本盗取；
- Secure：仅在 HTTPS 协议下传输 Cookie，避免明文传输被窃取。