JavaSecLab 本地靶场上手：在隔离环境搭建 Java 漏洞复现与代码审计练习环境

如果你正在寻找一个能反复复现 Java 漏洞、又能对照修复代码和审计笔记的练习环境，JavaSecLab 是一个值得关注的选项。它是一个基于 Spring Boot 的综合型 Java 漏洞靶场，仓库中围绕命令执行、SQL 执行、文件访问、模板渲染、反序列化、IDOR 等常见风险点提供了漏洞场景与修复对照思路，并把 source/sink 审计线索和流量分析作为练习材料的一部分。它适合应用安全学习者、代码审计初学者，以及需要为开发安全培训准备可复现案例的团队。使用前要先把边界说清楚：只在本地虚拟机、专用实验主机或书面授权的隔离环境中运行；不要接入生产网络，也不要把靶场实例直接暴露到公网。

准备：核验项目状态与隔离边界

先看仓库，不要照抄旧教程

部署前先打开官方仓库 whgojp/JavaSecLab，以 README、Release、最近提交和 issue 为准。搜索资料中可见 V1.5 版本树，地址为 JavaSecLab V1.5，但项目状态会变化，实际部署时应以仓库当前标签和说明为准。JavaSecLab 也有过针对 IDOR 控制器和 SecurityConfigurer 的修复提交，这说明逻辑漏洞模块、安全配置和默认访问策略会随版本调整，旧文章里的端口、账号、路径不一定仍然适用。

维护状态核验至少看四点：最近提交时间、Release 或标签、issue 中是否有阻塞性问题、README 是否更新了部署步骤。如果仓库说明与第三方转载不一致，优先相信仓库中的配置文件和启动说明。

环境与网络准备

JavaSecLab 提供 Docker 和源码两条常见路径。Docker 路径需要已安装 Docker 与 docker-compose；源码路径通常需要 JDK 和 Maven，仓库中可见的构建命令包括 mvn clean package -DskipTests。具体 JDK 版本、数据库版本和内存要求，以项目 README 和 pom.xml 为准。

隔离环境建议这样准备：

• 使用本地虚拟机、专用实验主机或云上独立 VPC，不要与办公网、生产网直接互通。
• 网络模式优先 host-only 或 NAT，默认拒绝外部入站；不要把安全组开放成 0.0.0.0/0。
• 为虚拟机做一次干净快照，记录初始状态，方便练习结束后回滚。
• 数据库使用一次性凭据，不要复用真实业务账号、密码或数据。
• 明确授权范围：只测试自己拥有或已获得书面授权的环境，不扫描互联网目标。

部署：Docker 与源码两条路径

Docker Compose 路径

仓库中包含 Docker 相关部署文件。最小流程可以按下面思路操作，具体服务名、文件路径和端口以 README 为准：

git clone https://github.com/whgojp/JavaSecLab.git
cd JavaSecLab
git tag
git checkout <按 README 选择的稳定标签>
docker compose up -d
docker compose ps
docker compose logs -f

搜索资料中的提交记录提示，Docker 部署过程中如果 SQL 文件没有自动初始化，也就是数据库为空时，需要手动导入 SQL 文件。遇到登录失败、模块无数据或页面报数据库错误时，先检查数据库是否为空，再按仓库说明导入初始化脚本。不要凭猜测导入外部 SQL 文件。

部分版本可能使用 docker-compose 命令而不是 docker compose，以本机安装版本和仓库说明为准。启动后先用 docker compose ps 确认容器状态，再看日志中是否有数据库连接失败、端口占用或初始化脚本未执行。

源码构建路径

如果选择源码运行，可在项目根目录执行：

mvn clean package -DskipTests
java -jar target/<按实际构建产物>.jar

构建前检查 application.yml 或对应配置文件中的数据库地址、端口、用户名和口令。不要把开发配置直接套到其他环境。若项目使用外部数据库，先确认数据库已创建并初始化；若使用内嵌数据库，则注意重启后数据是否保留。

关键配置与最小暴露面

无论哪条路径，部署后都建议做几项最小化处理：

• 将服务监听地址限制为 127.0.0.1 或隔离网段地址，不要监听 0.0.0.0 后直接映射到公网。
• 修改默认账号和口令；如果项目没有提供修改入口，至少在隔离环境中使用一次性凭据，并记录使用时间。
• 检查 SecurityConfigurer 相关放行规则，确认没有把全部路径或管理接口暴露给未认证访问。
• 关闭不需要的 actuator、调试端点、Swagger 或错误堆栈输出；这些内容适合本地排障，不适合对外暴露。
• 检查数据库端口是否只对容器网络或本机开放，不要将 MySQL 等端口映射到宿主机公网网卡。

验证：访问、模块与暴露面检查

功能验证

部署完成后，通过 http://127.0.0.1:<端口> 访问靶场。登录后先确认模块是否完整，再进入具体漏洞页面。JavaSecLab 覆盖的练习范围较广，常见包括 IDOR 横向与纵向越权、SQL 注入、命令执行、文件访问、模板渲染、反序列化以及响应输出类问题。部分场景还提供时间盲注等流量分析示例，适合把请求、响应与代码执行路径对应起来。

验证时不要只看页面能否打开，还要确认：

• 漏洞模块和修复模块是否能对照访问。
• 数据库是否有初始化数据。
• 请求能否正常进入后端控制器。
• 日志中是否出现异常堆栈或安全配置拦截。

网络暴露面检查

在宿主机和隔离网络内执行检查：

ss -lntp
docker compose ps
docker port <service>

然后从另一台非隔离主机尝试访问靶场端口，正常情况下应该连接失败或被防火墙拒绝。若可以访问，立即检查 Docker 端口映射、防火墙规则和云安全组。不要用公网 IP 直接测试靶场，也不要把靶场临时开放给无关人员。

默认配置检查

重点看默认账号、默认口令、JWT 密钥、数据库 root 口令、文件上传目录权限和日志目录权限。靶场的默认配置是为了方便复现漏洞，不是安全加固模板。练习结束后，这些凭据和配置应随环境一起清理或回滚。

练习：围绕 source/sink 与漏洞-修复对照

JavaSecLab 的一个价值在于把代码审计训练放进可运行环境。仓库资料中提到的常见工作流是：先定位 sink，例如命令执行、SQL 执行、文件访问、模板渲染、反序列化或响应输出；再反向追踪 source，例如请求参数、请求头、Cookie 或消息体；最后结合流量和修复代码验证判断。

推荐练习顺序可以这样安排：

1. 从 IDOR 和越权开始，理解水平越权与垂直越权的差别。
2. 进入 SQL 注入、命令执行、文件操作等经典漏洞，观察输入如何到达危险函数。
3. 练习模板注入、反序列化和响应输出类问题，注意不同框架和组件的触发条件。
4. 每个漏洞都记录请求包、响应、代码路径、修复差异和审计结论。
5. 用本地 SAST、DAST 或自定义规则验证检测效果，但只针对靶场自身。

记录比“打通”更重要。把 source、sink、调用链、修复提交和验证结果写进笔记，才能把一次复现转化为可复用的审计经验。

清理与回滚：练习结束后的必做项

练习结束后不要长期保留运行中的靶场。基础清理可以这样操作：

docker compose down
docker compose images
docker image prune

如果确认不需要保留数据库数据，可以使用 docker compose down -v 删除数据卷。这个命令会删除靶场数据库内容，执行前先确认没有需要导出的练习记录。之后删除临时克隆的源码目录、构建产物、代理配置、浏览器证书和 hosts 记录。修改过默认口令或密钥的环境，应直接回滚虚拟机快照，而不是继续复用。

回滚顺序建议为：停止容器或 Java 进程，删除临时数据卷和镜像，恢复虚拟机快照，清理凭据和浏览器数据，最后检查宿主机端口和防火墙规则是否恢复。若靶场曾接入过任何非隔离网络，还应检查访问日志，确认没有意外暴露。

常见故障

SQL 未初始化

数据库为空时，页面可能能打开但模块无数据，或登录直接失败。按仓库说明手动导入 SQL 文件，不要从不明来源下载 SQL 脚本。

端口、依赖与版本

端口冲突时改端口或停止占用进程。Maven 构建失败时检查 JDK 版本、依赖源和网络代理。Docker 启动失败时检查镜像拉取、卷权限和内存限制。版本差异较大时，优先切换到仓库中较稳定的标签，并重读对应版本的 README。

登录与权限异常

默认账号可能随版本变化，数据库未初始化也会导致登录失败。若出现大量路径被拦截，检查 SecurityConfigurer 和配置文件中的放行规则；若出现大量路径可未授权访问，说明默认安全策略不适合直接暴露，必须回到隔离环境使用。

JavaSecLab 适合作为 Java 漏洞复现与代码审计训练的本地资源，但它的前提是隔离、授权、最小暴露和及时清理。把它当作一个可回滚的实验环境来管理，而不是一个长期在线的服务，才能既获得练习价值，又不把风险带到真实网络中。