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

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

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

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

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

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

UserController.java

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

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

注意：配置的时候全部用 127.0.0.1，别用局域网IP

前端发给后端的登录请求，所以8080是对的

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

密码 123456 直接明文返回给了前端。

在浏览器 F12 控制台里也能看到响应内容，任何能打开开发者工具的人都能看到密码。

用户输入时（用户自己知道）

数据库里（应该是Hash，不是明文）

方案一：DTO 脱敏（推荐）

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

Controller 里做转换：

修复后返回的 JSON：

password 字段不再出现。

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

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

两种方案对比：

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

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

FileController.java

问题总结：

上传成功，文件被存到了服务器的 Web 目录下，返回了可访问路径 /uploads/shell.jsp。

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

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

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

白名单 vs 黑名单：

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

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

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

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

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

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

三个作用：

关键区别：

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

所有攻击场景都被阻断。

什么是图片马：

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

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

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

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

核心思想：

项目源码：GitHub - library-security-lab

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。