[原创] 基于图书管理系统的漏洞复现与代码审计（二）：敏感信息泄露与文件上传-WEB安全-看雪安全社区

⚠️ 免责声明：本项目仅用于安全学习与教育目的，严禁用于非法用途。如因使用本项目造成的任何法律后果，使用者自行承担全部责任。

本文是上一篇的续篇，继续对该图书管理系统进行代码审计。

上篇地址：https://bbs.kanxue.com/thread-290904.htm

上篇复现了 SQL 注入和水平越权两个漏洞，本篇继续审计出敏感信息泄露和文件上传两个漏洞。

---

## 一、敏感信息泄露漏洞

### 1.1 漏洞原理

后端接口直接返回完整的 `User` 实体对象，Spring Boot 内置的 Jackson 序列化器会自动将所有 getter 方法转成 JSON 字段，导致密码明文暴露在响应中。

**简单来说就是：** 后端把整个 User 对象返回给前端了，包括 password 字段。Spring Boot 自动把对象转成 JSON 的时候，会调用所有 getter 方法，`getPassword()` 也被调用了，密码就跟着 JSON 一起返回给前端了。

### 1.2 漏洞代码位置

**UserController.java**

```java
@PostMapping("/login")
public Result login(@RequestBody User user, HttpSession session) {
    User loginUser = userService.login(user.getUsername(), user.getPassword());
    if (loginUser != null) {
        // 直接把完整的 User 对象返回了，包括 password
        return Result.success(loginUser);
    }
    return Result.error("用户名或密码错误");
}
```

**问题：** `loginUser` 是从数据库查出来的完整 User 对象，里面有 password 字段。直接 `return Result.success(loginUser)`，Jackson 序列化器会把所有字段都转成 JSON，包括 password。

### 1.3 复现步骤

#### 步骤 1：正常登录，抓包

用 Burp Suite 拦截登录请求，正常登录用户A。

注意：**配置的时候全部用 127.0.0.1，别用局域网IP**
 ![](upload/attach/202609/1074589_USHDP9EVFGWTAAV.webp)
前端发给后端的登录请求，所以8080是对的

#### 步骤 2：查看响应，发现密码明文

放行请求后，查看 Burp 的 Response，可以看到返回的 JSON 里包含了 password 字段。

**密码 `123456` 直接明文返回给了前端。**
 ![](upload/attach/202609/1074589_X4YMXHE8GGPQEKM.webp)
#### 步骤 3：浏览器控制台验证

在浏览器 F12 控制台里也能看到响应内容，任何能打开开发者工具的人都能看到密码。
 ![](upload/attach/202609/1074589_A4B3WV6PZPSG2KY.webp)
### 1.4 危害

- 任何能抓包的人都能看到密码明文
- 如果前端代码不规范，password 可能直接渲染到页面上
- 本项目密码是明文存储，拖库后密码直接暴露（SQL 注入 + 敏感信息泄露组合拳）

###### 注:密码只能存在两个地方

- 用户输入时（用户自己知道）
  
- 数据库里（应该是Hash，不是明文）

### 1.5 修复方案

**方案一：DTO 脱敏（推荐）**

新建一个不含 password 字段的 DTO 类，返回给前端时只包含安全字段：

```java
// UserDTO.java —— 专门用于返回给前端的类，不含 password
public class UserDTO {
    private Integer id;
    private String username;
    private String role;
    // 没有 password 字段
}
```

Controller 里做转换：

```java
// 【修复代码】使用 DTO 过滤敏感字段
UserDTO userDTO = new UserDTO();
userDTO.setId(loginUser.getId());
userDTO.setUsername(loginUser.getUsername());
userDTO.setRole(loginUser.getRole());
return Result.success(userDTO);
```

修复后返回的 JSON：
 ![](upload/attach/202609/1074589_VMS38CR3VWBGK6S.webp)
password 字段不再出现。

**方案二：@JsonIgnore 注解（简单）**

在实体类字段上加注解，Jackson 序列化时跳过：

```java
public class User {
    private Integer id;
    private String username;

@JsonIgnore    // 序列化时跳过此字段
    private String password;
    private String role;
}
```

**两种方案对比：**

|     | DTO 脱敏 | @JsonIgnore |
| --- | --- | --- |
| 做法  | 新建不含敏感字段的类 | 实体类字段上加注解 |
| 优点  | 实体和返回数据彻底解耦 | 改一行代码就行 |
| 缺点  | 多写一个类 | 实体类和接口返回耦合 |
| 推荐度 | 正规项目推荐 | 简单项目可以 |

### 1.6 补充：密码存储安全

本项目密码是明文存储，这本身也是安全问题。正确的做法是用 BCrypt 做 Hash 存储：

- **自带 Salt**：每次加密结果不同，防彩虹表
- **慢哈希**：可调计算成本，抗暴力破解
- **不可逆**：只能验证不能反推

```java
// 注册时加密存储
user.setPassword(passwordEncoder.encode("123456"));
// 数据库存的是：$2a$10$x7k9m2...（Hash 值）

// 登录时验证
passwordEncoder.matches("123456", "$2a$10$x7k9m2...");  // true/false
```

---

## 二、文件上传漏洞

### 2.1 漏洞原理

后端上传接口没有做任何校验：不校验文件类型、不校验文件内容、保留原始文件名、存到 Web 根目录下。攻击者可以直接上传后门文件，通过 URL 访问执行任意系统命令，实现 GetShell。

### 2.2 漏洞代码位置

**FileController.java**

```java
@PostMapping("/upload")
public Result upload(@RequestParam("file") MultipartFile file, HttpServletRequest request) {
    try {
        // 第1步：直接拿到用户上传的原始文件名
        String fileName = file.getOriginalFilename();
        // 如果用户上传 shell.jsp → fileName = "shell.jsp"

// 第2步：存到 Web 根目录下的 uploads 目录
        String uploadPath = request.getServletContext().getRealPath("/uploads/");
        
        // 第3步：拼接完整路径，直接存
        File dest = new File(uploadPath + File.separator + fileName);
        if (!dest.getParentFile().exists()) {
            dest.getParentFile().mkdirs();
        }
        file.transferTo(dest);

// 第4步：返回可访问的 URL 路径
        return Result.success("/uploads/" + fileName);

} catch (Exception e) {
        e.printStackTrace();
        return Result.error("上传失败：" + e.getMessage());
    }
}
```

**问题总结：**

| 问题  | 说明  |
| --- | --- |
| 无文件类型校验 | 不检查扩展名，可以上传 .jsp |
| 无 MIME 校验 | 不检查 Content-Type |
| 无文件内容校验 | 不检查文件头（Magic Number） |
| 保留原始文件名 | 攻击者控制文件名，知道访问路径 |
| 存到 Web 根目录 | Tomcat 可直接解析执行 .jsp |

### 2.3 复现步骤
#### 步骤 1：直接用 curl 上传后门文件
 ![](upload/attach/202609/1074589_HVCCFDP8ZRKYJJG.webp)
#### 步骤 2：Burp 抓包对比
 ![](upload/attach/202609/1074589_3ZYGJKY48ETW7AY.webp)
上传成功，文件被存到了服务器的 Web 目录下，返回了可访问路径 /uploads/shell.jsp。

后端没有做任何校验——不校验扩展名、不校验MIME类型、不校验文件内容、
保留原始文件名、存到Web可访问目录。

如果部署在传统 Tomcat 容器中（非 Spring Boot 内嵌），
访问

```http
http://localhost:8080/uploads/shell.jsp?cmd=whoami
```

就能执行系统命令，实现 RCE。

### 2.4 攻击链总结

```
制作后门文件
    ↓
上传到服务器（无校验，直接存）
    ↓
通过 URL 访问文件
    ↓
Tomcat 把 .jsp 当代码执行
    ↓
cmd 参数传命令 → RCE
```

### 2.5 修复方案：四层防御

```java
// 定义两个白名单
private static final List<String> ALLOWED_SUFFIX = Arrays.asList("jpg", "jpeg", "png", "gif");
private static final List<String> ALLOWED_MIME = Arrays.asList("image/jpeg", "image/png", "image/gif");

@PostMapping("/upload")
public Result uploadSafe(@RequestParam("file") MultipartFile file) {
    try {
        String originalName = file.getOriginalFilename();

// 第0层：空值检查
        if (originalName == null || !originalName.contains(".")) {
            return Result.error("文件名不能为空或无扩展名");
        }

// 提取后缀
        String suffix = originalName.substring(originalName.lastIndexOf(".") + 1).toLowerCase();

// 第1层：白名单校验（扩展名 + MIME 类型）
        if (!ALLOWED_SUFFIX.contains(suffix) || !ALLOWED_MIME.contains(file.getContentType())) {
            return Result.error("只允许上传jpg/png/gif图片");
        }

// 第2层：Magic Number 文件头校验
        byte[] header = file.getBytes();
        if (header.length < 4) return Result.error("文件异常");

String magic = bytesToHex(Arrays.copyOfRange(header, 0, 4));
        if (!magic.startsWith("ffd8") && !magic.startsWith("89504e47") && !magic.startsWith("47494638")) {
            return Result.error("文件类型不匹配");
        }

// 第3层：UUID 重命名
        String newName = UUID.randomUUID().toString() + "." + suffix;

// 第4层：目录隔离（存到 Web 根目录外）
        String uploadPath = "E:/Code/Library/uploads/images/";
        File dest = new File(uploadPath + newName);
        dest.getParentFile().mkdirs();
        file.transferTo(dest);

return Result.success("/static/images/" + newName);

} catch (Exception e) {
        e.printStackTrace();
        return Result.error("上传失败：" + e.getMessage());
    }
}

// 辅助方法：字节数组转十六进制字符串
private static String bytesToHex(byte[] bytes) {
    StringBuilder sb = new StringBuilder();
    for (byte b : bytes) {
        sb.append(String.format("%02x", b));
    }
    return sb.toString();
}
```

### 2.6 四层防御详解

#### 第1层：白名单校验（扩展名 + MIME）

```java
String suffix = originalName.substring(originalName.lastIndexOf(".") + 1).toLowerCase();
if (!ALLOWED_SUFFIX.contains(suffix) || !ALLOWED_MIME.contains(file.getContentType())) {
    return Result.error("只允许上传jpg/png/gif图片");
}
```

**白名单 vs 黑名单：**

- 白名单：只允许 jpg/jpeg/png/gif → 新危险类型默认被拒绝 ✅
- 黑名单：拒绝 jsp/php/exe... → 新危险类型可能遗漏 ❌

为什么要同时校验扩展名和 MIME？

因为攻击者可以同时改 filename 和 Content-Type，两个都校验才安全，为了挡住只改一个的攻击者。

#### 第2层：Magic Number 文件头校验

每种文件格式开头都有固定的字节标识：

| 文件类型 | Magic Number（hex） | 说明  |
| --- | --- | --- |
| JPEG | `FF D8 FF` | JPEG 文件固定开头 |
| PNG | `89 50 4E 47` | PNG 文件固定开头 |
| GIF | `47 49 46 38` | GIF 文件固定开头（GIF8） |

读取文件前 4 个字节，转成十六进制，检查是否匹配已知的图片文件头。

**作用：** 防止攻击者把纯文本脚本代码改扩展名为 jpg 上传。

**局限：** 拦不住图片马（真 JPG 头 + 恶意代码），因为图片马的文件头是真的 JPG 格式。

#### 第3层：UUID 重命名

```java
String newName = UUID.randomUUID().toString() + "." + suffix;
// 结果类似：550e8400-e29b-41d4-a716-446655440000.jpg
```

**三个作用：**

1. **防路径穿越**：攻击者传文件名 `../../etc/passwd`，重命名后变成 UUID.jpg，路径穿越失效
2. **防文件覆盖**：不同用户上传同名文件不会互相覆盖
3. **攻击者不知道文件名**：无法直接通过 URL 访问

#### 第4层：目录隔离（兜底）

```java
String uploadPath = "E:/Code/Library/uploads/images/";
// 不在 Web 根目录下，Tomcat 无法直接解析执行
```

**关键区别：**

```
漏洞版：存到 Web 根目录下 → Tomcat 能解析 .jsp → 执行代码 → RCE
修复版：存到 Web 根目录外 → Tomcat 找不到这个目录 → 访问返回 404 → 无法执行
```

**这是最后的兜底防御**——即使图片马通过了前面所有校验，文件存到 Web 根目录外，Tomcat 不会把它当作脚本解析执行，攻击链断了。

### 2.7 修复验证

| 测试场景 | 结果  |
| --- | --- |
| 上传正常图片 cat.jpg | ✅ 成功，能正常访问 |
| 直接上传 shell.jsp | ❌ 被白名单拒绝 |
| 改扩展名 shell.jpg（纯文本内容） | ❌ 被 Magic Number 拦住 |
| 上传图片马（真JPG头+恶意代码） | ❌ 通过前3层，但被目录隔离拦住，访问返回 404 |
| 路径穿越 ../../etc/passwd | ❌ UUID 重命名后失效 |

所有攻击场景都被阻断。

### 2.8 关于图片马

**什么是图片马：**

把一个正常图片和一个后门文件拼在一起：

```
copy /b tree.jpg + shell.jsp shell.jpg
```

合并后的文件，前面是正常的 JPG 文件头和图片数据，后面藏着恶意代码。

**图片马为什么能通过前 3 层防御：**

| 防御层 | 校验内容 | 图片马的表现 | 结果  |
| --- | --- | --- | --- |
| 白名单 | 扩展名是 .jpg | .jpg | 通过 ✅ |
| MIME | Content-Type 是 image/jpeg | image/jpeg | 通过 ✅ |
| Magic Number | 文件头是 FF D8 FF | 真的 JPG 文件头 | 通过 ✅ |

**最终靠目录隔离兜底：** 文件存到 Web 根目录外，Tomcat 不解析，访问返回 404，攻击链断了。

---

## 三、总结

| 漏洞  | 原因  | 危害  | 修复方案 |
| --- | --- | --- | --- |
| 敏感信息泄露 | 直接返回 User 实体，Jackson 自动序列化所有字段 | 密码明文暴露 | DTO 脱敏，不返回敏感字段 |
| 文件上传 | 无校验 + 保留原文件名 + 存到 Web 根目录 | GetShell → RCE → 完全控制服务器 | 四层防御：白名单 + Magic Number + UUID 重命名 + 目录隔离 |

**核心思想：**

- 敏感信息泄露：返回给前端的数据要做过滤，不能直接把实体对象丢出去
- 文件上传：没有单一防御能拦住所有攻击，需要多层防御（纵深防御），任何一层断了攻击链就成功了

项目源码：<a href="elink@cfcK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1j5`.">GitHub - library-security-lab</a>

登录后可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！