11服务器端请求伪造【SSRF】

## 什么是SSRF

SSRF（Server-Side Request Forgery，服务器端请求伪造）是一种由攻击者构造恶意请求，诱导服务器发起**非预期网络请求**的攻击方式。

其核心危害在于：攻击者通过控制服务器的请求行为，突破服务器的网络边界（如防火墙限制），访问或攻击本不应被外部触及的内部资源（如内网服务、本地文件、敏感系统等）。在其他情况下，攻击者甚至可能强制将内部服务器连接到任意外部系统，这可能会泄露敏感数据。

## 攻击原理

SSRF 的本质是服务器被 “劫持” 为攻击跳板，具体流程如下：

**1. 存在风险的功能场景**

服务器存在需要 “主动发起网络请求” 的功能，例如：

- 图片上传功能：允许用户输入图片 URL，服务器自动下载并保存；
- 链接预览功能：根据用户提供的 URL，服务器抓取页面内容生成摘要；
- 第三方数据集成：服务器根据用户输入的 API 地址，发起请求获取数据。

**2. 攻击者构造恶意输入**

攻击者向存在风险的功能场景提交**恶意 URL 或请求参数**（而非正常的外部资源地址），例如：

- 指向内网 IP 的地址（如  `http://192.168.1.1/admin` ，目标是服务器所在内网的管理页面）；
- 本地文件路径（如  file:///etc/passwd ，试图读取服务器本地敏感文件）；
- 特殊协议请求（如  gopher://127.0.0.1:6379/... ，攻击本地 Redis 服务）。

**3. 服务器执行恶意请求**

由于服务器未对用户输入的 URL 进行严格验证，直接使用该 URL 发起请求。此时，请求是以**服务器的身份和网络权限**执行的：

- 服务器可访问的内网资源（如数据库、内网管理系统），攻击者通过 SSRF 间接访问；
- 服务器本地的敏感文件（如配置文件、密钥），攻击者通过 SSRF 读取；
- 服务器可连接的端口，攻击者通过 SSRF 进行端口扫描，探测内网拓扑。

**4. 获取攻击结果**

服务器将请求的响应结果（如内网页面内容、文件内容）返回给攻击者，或通过响应差异（如请求成功 / 失败的时间差）推断内网信息。

## 典型应用场景与危害

SSRF 攻击通常利用信任关系来执行未经授权的操作，这些信任关系可能存在于服务器之间，也可能存在于同一组织内的其他后端系统之间。

SSRF 的危害程度取决于服务器的网络权限和内部资源的敏感性。

**1. 探测内部网络拓扑与服务**

攻击者通过构造不同的内网 IP 和端口（如  `http://192.168.0.1:80` 、 `http://10.0.0.5:3306` ），利用服务器作为跳板，探测内网中存活的主机、开放的端口及运行的服务（如 MySQL、Redis、Elasticsearch 等），为后续攻击收集信息。

**2. 攻击内网服务**

许多内网服务（如 Redis、MongoDB、ZooKeeper）默认不开启认证，或仅允许内网访问。攻击者可通过 SSRF 向这些服务发送恶意指令，例如：

- 向内网 Redis 服务器发送命令，写入恶意公钥到  ~/.ssh/authorized_keys ，获取服务器 SSH 登录权限；
- 向 Elasticsearch 发送 API 请求，删除索引或读取敏感数据。

**3. 读取文本敏感文件**

通过支持 file 协议的服务器（如 PHP 的 file_get_contents 、Python 的 urllib ），攻击者可构造 file:// 协议的 URL，读取服务器本地文件：

- 系统文件（如  /etc/passwd 、 /etc/hosts ）；
- 配置文件（如数据库密码配置  ./config/db.php 、SSH 私钥  /root/.ssh/id_rsa ）；
- 日志文件（如 Web 服务器日志  /var/log/nginx/access.log ，可能包含用户凭证）。

**4. 绕过防火墙与网络隔离**

服务器通常部署在 DMZ（隔离区），可有限访问内网，而外部攻击者直接访问内网会被防火墙拦截。SSRF 利用服务器的网络位置，绕过防火墙限制，直接与内网交互。

## 防护措施

防护 SSRF 的核心思路是：严格限制服务器发起的请求范围，避免其被用于访问非预期资源。

**1. 限制允许的协议**

仅允许服务器使用必要且安全的协议（如 http 、 https ），禁止危险协议：

- 禁用 file （读取本地文件）、 gopher （构造复杂请求，攻击 Redis 等服务）、 ftp （访问文件服务器）、 dict （探测端口）等协议；
- 验证 URL 的协议部分，若不在白名单内则拒绝请求。

**2. 限制请求的目标地址**

- 禁止访问内网 IP：校验请求的目标 IP，拒绝所有内网网段（如 10.0.0.0/8 、 192.168.0.0/16 、 127.0.0.0/8 ）及localhost；
- 使用 IP 白名单：仅允许服务器请求预先配置的可信域名 / IP（如业务合作的第三方 API 地址），拒绝任意用户输入的地址；
- 处理域名解析风险：若允许域名，需先将域名解析为 IP，再检查 IP 是否在禁止列表（防止攻击者通过恶意 DNS 将域名解析到内网 IP）。

**3. 限制请求端口**

服务器发起的请求应限制在常见端口（如 80 、 443 ），禁止访问高危端口（如 22 （SSH）、 3306 （MySQL）、 6379 （Redis）等）。

**4. 过滤返回内容**

即使请求被允许，也应限制服务器返回给用户的响应内容：

- 不返回详细的错误信息（如 “连接被拒绝”“超时” 等，避免攻击者通过差异判断内网状态）；
- 对返回内容进行过滤，仅提取业务所需数据（如图片尺寸、标题），不返回完整响应体。

**5. 禁用不必要的功能**

若业务不需要 “根据用户输入 URL 发起请求” 的功能（如图片 URL 上传、链接预览），直接禁用或采用更安全的替代方案（如仅允许用户上传本地文件，而非通过 URL 获取）。

**6. 使用安全的库与配置**

- 避免使用危险的函数（如 PHP 的 file_get_contents 、 curl_exec ，若必须使用，严格校验参数）；
- 配置网络库禁止跟随重定向（防止攻击者通过 302 重定向将请求转向内网资源）。

## XSS、CSRF与SSRF

| 特性         | XSS（跨站脚本攻击）                                          | CSRF（跨站请求伪造）                                         | SSRF（服务器端请求伪造）                                     |
| ------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| **定义**     | 攻击者将恶意脚本注入目标网站，诱导受害者浏览器执行，窃取用户数据或会话信息。 | 攻击者诱导已登录目标网站的用户，触发跨站请求，利用用户身份执行非预期操作。 | 攻击者构造恶意输入，诱导服务器发起非预期请求，利用服务器权限访问内网或本地资源。 |
| **核心原理** | 利用网站对用户输入的过滤不足，让恶意脚本在受害者浏览器中执行。 | 利用用户的已认证状态（如 Cookie），让服务器误判跨站请求为用户主动操作。 | 利用服务器的 “主动请求功能”（如根据 URL 获取资源），让服务器作为跳板访问受限资源。 |
| **发起者**   | 恶意脚本在**受害者的浏览器**中执行（客户端行为）。           | 恶意请求由**受害者的浏览器**发起（客户端行为），但利用用户身份。 | 恶意请求由**目标服务器**主动发起（服务器端行为）。           |
| **利用对象** | 目标网站对用户输入的信任（未严格过滤脚本）。                 | 目标服务器对用户身份凭证（如 Cookie）的信任，以及用户的已登录状态。 | 服务器对用户输入 URL 的信任（未严格校验请求目标），以及服务器的网络访问权限。 |
| **攻击目标** | 受害者的敏感数据（如 Cookie、账号密码）、会话信息，或篡改页面内容。 | 服务器上的用户操作（如转账、改密码、删数据），以用户身份执行。 | 服务器可访问的内网资源（如数据库、管理系统）、本地文件（如配置文件）、端口服务等。 |
| **典型场景** | 在评论区注入 \<script> 标签窃取 Cookie；构造钓鱼页面欺骗用户输入信息。 | 诱导用户点击链接，触发自动提交的转账表单；通过图片标签触发删除操作的 GET 请求。 | 利用 “URL 预览” 功能让服务器访问 file:///etc/passwd 读取文件；让服务器访问内网 Redis 服务。 |
| **防御核心** | 过滤用户输入（转义特殊字符）、限制脚本执行（如 CSP）、使用 HttpOnly Cookie。 | 验证 CSRF Token、设置 SameSite Cookie、验证 Referer/Origin、敏感操作二次验证。 | 限制请求协议（禁用 file/gopher 等）、禁止访问内网 IP、限制端口、过滤返回内容。 |

简单总结：

- XSS 是 “在受害者浏览器注入脚本偷数据”；
- CSRF 是 “借受害者身份让服务器做事”；
- SSRF 是 “借服务器身份访问内网资源”。

## 实验

靶机地址：https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost

已知：该实验室具有库存检查功能，可以从内部系统获取数据。

任务：请将库存检查 URL 更改为访问管理界面 `http://localhost/admin` 并删除用户 carlos 。

1、访问靶机，类似于购物网站。

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

2、直接访问/admin目录呢。

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

返回的信息为：仅当以管理员身份登录或从环回请求时，管理界面才可用。

环回请求指**请求的发起者（如服务器、应用进程、客户端）与接收者（服务或端口）属于同一个网络节点或进程**，请求不经过外部网络，仅在 “本地闭环” 中传输。

**常用标识**：

- IPv4： 127.0.0.1 （整个 127.0.0.0/8 网段均为环回地址，指向本地）
- IPv6： ::1 
- 主机名： localhost （默认解析为环回地址，受本地 hosts 文件影响）

3、访问某个产品，点击“检查库存”，抓取数据包。

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

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

观察到stockApi参数的值是http的URL地址。

4、根据之前admin路径的提示信息，将参数修改为：

```txt
 http://localhost/admin
```

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

放包。

5、神奇的地方出现了，在当前商品的下方出现了用户删除页面。

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

6、所以根据任务，点击删除carlos，然后进行抓包。

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

获取完整的URL：

```txt
 https://0a2a001d03041365830e064e00c8003e.web-security-academy.net/admin/delete?username=carlos 
```

将域名改为localhost，即为：

```txt
 http://localhost/admin/delete?username=carlos 
```

7、再次抓取检查库存的数据包，将参数修改为删除carlos的URL。

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

放包。

8、删除成功，过关。

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

9、还可以再将参数修改为`http://localhost/admin`进行验证。

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