企业官网建设流程全解析

OWASP SecurityShepherd 这个项目，在 Web 安全训练圈子里算是一个比较特别的存在。它不是那种堆漏洞的“靶场集合”，而是一套带完整教学逻辑、积分考核和权限收敛体系的闭环训练平台。如果你想把安全培训从“看视频、听概念”变成“动手打靶、自动评分、可量化追踪”，那这套架构非常值得拆开来仔细看一遍。这篇文章我会从组件划分、授权机制、漏洞实现到部署运维，把这个项目的骨架和血肉都过一遍，也把我实际部署和改造过程中踩过的坑一并讲清楚。

1. 项目定位与设计思路拆解

先把这个项目放在合适的坐标里理解。OWASP SecurityShepherd 是 OWASP 旗下一个开源的教学型 Web 应用，核心目标是训练学员识别和利用常见 Web 漏洞，同时让教员能够实时掌握每位学员的进度和水平。它和你平时看到的 DVWA、WebGoat 这类单机靶场有一个明显区别：SecurityShepherd 更像一套“教学管理系统 + 靶场环境”的组合体，而不是单纯的漏洞演示工具。

1.1 为什么需要这样一套系统

传统安全教学有个很现实的痛点：学员看完课件、做完实验，到底学会了多少，很难量化。如果只是让学员在本地起个 DVWA，练完就关，教员拿不到任何反馈数据。SecurityShepherd 在设计之初就把这个问题当成核心命题，所以它内置了三件事：

• 分层级的训练关卡（从易到难、按漏洞类型组织）
• 自动判分的题库系统（不光是做题，还要在真实漏洞环境里完成任务）
• 统一的评分与排名机制（基于积分体系，实时反映学员能力变化）

这三件事合在一起，就形成了一个“教、练、考、评”的闭环。学员在这套系统里不是漫无目的地扫描，而是被任务驱动着去理解漏洞原理、构造 Payload、拿到 Flag、提交积分。教员则可以通过后台看板掌握整体学习进度，识别出哪些知识点是普遍薄弱项。

1.2 它解决的三个具体问题

从我实际使用的体验来看，这套系统的设计思路解决了三个非常具体的问题：

第一个是权限隔离。学员在训练过程中需要访问恶意构造的页面、提交攻击语句，但系统不能让学员碰到管理后台，更不能让学员之间互相干扰。SecurityShepherd 通过一套“堡垒模式（Fortress Mode）”授权机制，把学员操作限制在训练模块内，并且对访问的 URL、请求方法、会话状态都做了校验。这个设计在同类靶场里比较少见，但又是真实企业安全培训里非常需要的功能。

第二个是可持续跟踪。每个学员的账号、积分、已过关卡、做对做错的题目都会记录在数据库中。这意味着培训不是一次性的，而是可以分阶段、分模块推进的。学员今天练 SQL 注入，下周回来继续练 XSS，系统能准确告诉他上次停在哪里、哪些题目还没完成。

第三个是难度递进的训练曲线。SecurityShepherd 的关卡不是平铺的，而是按漏洞类型分类、按难度分级。每个分类下有不同的关卡实例，从“能看到报错信息即可判断注入点”的基础关，到“需要绕过过滤、拼闭合语句”的进阶关，配合积分差异，自然形成了一条学习曲线。

2. 技术栈选型与环境架构

在分析组件之前，有必要先把这套系统的技术底座讲明白。SecurityShepherd 选择了一套看起来有点“老”但实际很稳的技术组合：Java EE + JSP + Tomcat + MySQL（默认兼容 H2 内存库）。很多第一次接触这个项目的人会问，为什么不用前后端分离？为什么不用更现代的框架？这其实是有意为之。

2.1 老技术栈背后的教学逻辑

安全训练平台有一个被很多人忽略的设计原则：漏洞环境越接近真实年代，训练效果越好。现在生产环境里大量遗留系统还是 JSP + Servlet 架构，经典的 SQL 注入、XSS、CSRF 漏洞在这些系统里依旧高发。SecurityShepherd 直接使用 JSP 作为页面层，服务端渲染、Session 管理、表单提交这些机制都是原生的，学员在其中构造攻击请求时，面对的交互方式和真实老系统几乎一致。

这一点和用 React + Node 重写的靶场有本质区别。现代框架默认带了很多安全机制（比如自动转义、CSRF Token），要把漏洞“反向制造”出来反而要绕很多弯，而且训练出来的手感不真实。SecurityShepherd 这种“返璞归真”的技术选型，恰恰是它教学价值的核心。

2.2 核心组件一览

从架构上看，这个项目大致由四类组件构成：

其中比较关键的是 Filter 层的授权拦截机制，后面我会单独展开。整体项目是一个典型的 “MVC + DAO” 分层结构，没有引入过多框架，代码读起来不费力，改起来也顺手。

2.3 默认内存库与生产库的切换思路

SecurityShepherd 默认配置了 H2 内存数据库，目的很简单：让初学者拿到代码后一条命令就能跑起来，看不到任何数据库安装的障碍。但内存库有个致命问题——服务一重启，所有学员账号、积分、闯关记录全没了。如果你是用来做正式培训，或者部署到服务器上供多人长期使用，必须切换 MySQL。

切换过程不复杂，核心是修改数据源配置，把驱动、连接串、用户名密码换成 MySQL 的即可。有一点要特别注意：数据库表结构中的中文内容可能出现乱码，连接串上要显式加上字符集参数。这部分我在后面“部署与运维”里会给出现成的配置参考。

3. 核心模块与功能实现解析

这一节是整篇文章的重头戏。我会把 SecurityShepherd 的内部模块按照“学员可见功能”和“后台管理功能”两条线拆开讲，同时把每个模块背后的实现机制说清楚。

3.1 训练关卡模块（Lessons）

训练关卡是学员最常打交道的部分。每个关卡本质上是一个配置了漏洞的 JSP 页面，页面里包含了用于演示漏洞的输入框、按钮、回显区域。学员的任务就是通过构造特定输入，让页面产生非预期的行为，从而拿到系统的“Flag”或完成某个判定条件。

以 SQL 注入关卡为例，页面里通常会有一个搜索框，后端代码把用户输入直接拼接进 SQL 语句。学员输入' or 1=1 --之后，页面回显出全部数据，即判定过关。在代码层面，判分逻辑通常会检查请求参数里是否包含了特定关键字，或者页面响应中是否出现了期望的数据库报错信息。

每个关卡在数据库中都有对应记录，包括关卡名称、所属分类、难度等级、积分值。学员过关后，系统会自动将积分加到该学员名下，并记录完成时间。这套机制让“训练”和“考核”的边界变得很模糊——学员其实一直在做任务，而任务本身就有打分能力。

3.2 题库考核模块（Assessments）

如果说关卡是“练习”，那题库就是“测验”。SecurityShepherd 内置了一批安全知识选择题，题面可能涉及漏洞原理、HTTP 协议、加密基础等。和普通考试系统不同，这里的题目顺序和选项顺序是随机化的，能有效避免学员之间互相传答案。

这里有一个设计细节值得点赞：题库系统和关卡系统共享同一个积分池。学员做对题目加分、过关也加分，但不同类型任务的分值权重不同。这样一来，只刷题不实战的人分数不会太高，只打关不学理论的人也会在总分上吃亏。它本质上是在用分数引导学员“两手都要抓”。

3.3 积分、排名与等级体系

积分体系是这套系统的“神经系统”。学员每完成一个任务，积分变动都会实时反映在排行榜上。排行榜数据在数据库中持久化，刷新后依然保留。

具体的积分规则可以简单概括为：

• 基础关卡，过关后加较低积分（如 5 ~ 15 分）
• 进阶关卡，过关后加中等积分（如 20 ~ 40 分）
• 挑战关卡，过关后加高积分（如 50 分以上）
• 答对题库题目，按难易度加 2 ~ 8 分

排名则按总积分降序排列。除了总排名，系统还按关卡分类设计了独立进度条，让学员能直观看到自己在哪个漏洞类型上积累的经验值更多。这种“总分 + 分类分”的双维展示方式，比单纯一个总分更能反映能力结构。

3.4 后台管理模块（Instructor / Admin）

后台管理是教员视角的核心入口。管理员可以创建班级、批量导入学员账号、重置学员密码、查看所有学员的详细通关记录。还可以控制哪些关卡对当前学期开放、哪些暂时隐藏。

这个模块的实现思路也很直白：一组独立的 JSP 管理页面 + 一组管理员专用的 DAO 方法。权限控制靠的是 Session 里的角色标记，管理员账号在数据库中有单独的标识字段。因为这套系统默认面向高校教学场景，所以后台功能围绕“老师管理学生”这个核心来设计，没有复杂的 RBAC 权限树，但够用。

4. 堡垒模式与授权机制：这套系统最独特的架构设计

接下来重点讲我认为 SecurityShepherd 最有价值的设计——堡垒模式（Fortress Mode）。这是大多数靶场没有、但企业安全培训非常需要的功能。

4.1 为什么需要堡垒模式

在真实的攻防训练中有一个难题：学员在靶机上做攻击测试，如果靶场环境隔离做不好，学员可能通过跳板攻击到内网其他机器，甚至把靶场自身的管理接口打穿。SecurityShepherd 把“坏事”限制在可控范围内，通过堡垒模式将学员的操作路径强制约束在系统允许的 URL 规则内，越权访问会被弹回并记录日志。

从实现角度来看，这个机制类似一个“访问代理”或“网关过滤器”。当学员点击页面里的“进入关卡”按钮时，系统不是直接跳转到目标 URL，而是先经过一层校验：当前用户是否具备访问该关卡的授权？当前请求的 URL 是否符合该关卡的合法路径？校验通过才真正加载关卡页面。

4.2 授权数据模型与动态配置

在这种机制背后，数据库中有一组授权关系表。简单来说，每一条授权记录都包含了“哪个学员、在哪个学期、被授权访问哪些关卡”。管理员在后台把关卡授权给某个班级后，该班级下所有学员账号才具备访问这些关卡的资格。

这里有个非常实用的细节：授权不是静态写死在代码里的，而是可以在管理后台动态调整的。比如这学期只教 SQL 注入和 XSS，管理员只需勾选对应分类的关卡，其他所有关卡对学员自动隐藏和拦截。这意味着同一套系统，不同学期、不同班级可以有不同的训练范围，不需要重新部署。

4.3 拦截器链的实现逻辑

从代码层面看，授权校验通常在 Filter 或 Servlet 的预处理逻辑中完成。大致流程如下：

1. 请求进入系统，携带 Session。
2. 系统判断当前请求的 URI 是否属于关卡路径。
3. 如果是，则读取当前用户的授权列表。
4. 校验该 URI 是否被授权，未被授权则中断响应，返回提示页。
5. 校验通过则放行，进入关卡逻辑。

这种“先校验，后放行”的链式处理方式，本质上是一种简单而有效的访问控制列表（ACL）实现。对于教学系统来说，它的价值不仅在于防止学员超前学习，更在于避免有人通过猜测 URL 直接访问尚未开放的题目答案页。

4.4 会话固定与重放防护

除了访问控制，堡垒模式还兼顾了一些基础会话安全需求。学员 ID 和关卡 ID 的绑定关系不会简单地放在 URL 参数里，而是和服务端 Session 维护的状态进行匹配。这样做的好处是，学员无法通过篡改 URL 参数来冒充他人身份或访问不属于自己的关卡记录。

在使用这套模式时，我遇到过一个典型问题：如果学员长时间停留在一个页面，Session 过期后，再点击“提交 Flag”就会跳回登录页，刚才的劳动成果没保存。解决思路有两个方向，一是调大 Session 超时时间，适合长时间实训课；二是改代码，在提交环节增加防丢失的临时缓存。具体取舍我在后面会展开。

5. 漏洞训练模块的技术实现解析

这一节我们从“怎么教”下沉到“教什么”，具体看看 SecurityShepherd 里几个代表性漏洞模块是怎么用代码实现的。这些实现对于那些想自建关卡的人来说，是很好的参考蓝本。

5.1 SQL 注入模块的实现思路

SQL 注入关卡在代码层面就是故意写一句拼接 SQL。典型的写法是：

String query = "SELECT * FROM users WHERE username = '" + request.getParameter("username") + "'"; Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(query);

这里没有任何参数化查询，没有预编译，用户输入直接进入 SQL 语句。训练时学员输入' OR '1'='1，就能把整个表的数据带出来。页面会设计一个明显的回显区域，将查询结果以表格的方式渲染在页面上，学员能清楚地看到自己的注入是否生效。

过关条件设计得也很直白：当响应页面中出现“Success”或特定标识时，系统判定当前任务完成。这个判定可以用一个隐藏字段或者服务端变量来实现，学员看不到、但又能通过操作触发。

教学层面的设计在于，这个模块不会只给一个注入点，它会按难度设计不同形态：字符型注入、数字型注入、带括号的注入、盲注。每个形态对应一个关卡，学员必须逐关打通，才能拿到该分类下全部的积分。

5.2 XSS 模块的实现思路

XSS 关卡的核心代码通常是将用户输入直接输出到页面：

out.println("<div>" + request.getParameter("comment") + "</div>");

没有 HTML 编码、没有过滤、直接输出。学员提交<script>alert(1)</script>后，弹窗出现，即算过关。

更有意思的是 XSS 分类下的进阶关卡，它会模拟一个“留言板 + 管理员后台”的场景。学员提交的留言会被“管理员”访问，而管理员的 Cookie 就保存在 Session 里。学员要做的就是构造一个窃取 Cookie 的 Payload，将数据发送到指定接口。这个场景让学员理解存储型 XSS 的真正危害：不只是弹个窗，而是能拿到管理员身份。

5.3 访问控制与 CSRF 模块的编排

访问控制关卡模拟的是一个多用户文件管理系统。每个用户登录后只能查看自己的文件，但如果学员在请求中修改了 URL 里的用户 ID，就可能越权读取到其他用户的数据。这个关卡的教学目标是让学员意识到“前端隐藏按钮 ≠ 后端权限控制”。

CSRF 关卡则设计了一个“修改密码”的功能。这个功能只验证了 Session 是否有效，但没有校验请求来源。学员需要构造一个自动提交表单的恶意页面，让“受害者”访问，从而在不知情的情况下修改密码。通过这个关卡，学员能直观理解为什么现代应用都要加 CSRF Token。

5.4 关卡难度编排与依赖关系

还有个细节值得提一下：关卡之间有依赖关系。某些高级关卡必须等前置关卡通关后才能解锁。这种编排避免了学员“跳级”打关导致的挫败感，也让训练路径更清晰。

后台数据结构中，关卡表通常会包含“前置关卡 ID”字段。解锁逻辑在关卡入口处做判断，如果前置未完成，直接提示“请先完成前置关卡”。这个设计和游戏中的任务链很像，但在安全训练平台里能有效保证学习顺序。

6. 数据持久化与状态管理

作为一套多人使用的教学系统，SecurityShepherd 的数据持久化设计虽然简单，但有一些值得注意的取舍。

6.1 实体的关系模型

核心数据表大致包括：用户表、关卡表、积分记录表、授权表、题库表、答题记录表、班级表。

用户表和关卡表之间是多对多关系，通过积分记录表关联。授权表则记录的是“班级-关卡-学期”的授权关系。整体模型不算复杂，但足以支撑教学场景的全部核心流程。

这里有一个设计细节：积分记录表不只是存一个数字，它还会记录“加分来源”（是过关还是答题）、“操作时间”、“操作人 ID”。这就为后台统计提供了原始数据。如果培训结束后要出学员能力报告，直接按来源类型聚合即可，不需要额外开发。

6.2 H2 内存模式与 MySQL 生产模式

前面提到，默认 H2 内存模式是给快速体验用的。我在实际部署时直接切换到了 MySQL，原因很简单：我要做为期一个月的培训跟踪，服务重启后数据不能丢。

MySQL 模式的连接配置一般在项目的资源文件中。改动注意两点：一是数据库连接串要指定useUnicode=true&characterEncoding=utf8，否则中文内容会乱码；二是初始化 SQL 脚本要提前执行，建好库表。项目本身提供了建表脚本，直接导入即可。

6.3 Session 状态管理与会话超时

这个系统的 Session 管理主要有两个作用：一是维持学员登录状态，二是追踪当前正在训练的关卡。出于教学场景的考虑，Session 超时不能设置得太短。我记得默认超时可能是 30 分钟左右，但在实际实训课中，学员经常边看课件边切回靶场，超过 30 分钟不操作很常见。如果超时太短，重复登录的体验会非常差。

解决方案很简单，在 web.xml 里调大 Session 超时时间：

<session-config> <session-timeout>120</session-timeout> </session-config>

这样设置后，一节两个小时的实训课基本不会中途掉线。如果你是做线上长期练习，建议设为 60 分钟，兼顾安全和体验。

7. 部署实操与配置要点

这部分我直接给出我在服务器上完整部署一遍的步骤和要点，照着做基本能跑起来。

7.1 构建前的环境检查

先确认本机环境：

• JDK 1.8 或更高版本（项目比较老，用 8 最稳）
• Maven 3.x
• Tomcat 8.5 或 9.x
• MySQL 5.7 或 8.x（如果用 H2 内存模式则不需要）

构建命令很简单：

mvn clean package

执行完会在target/目录下生成 WAR 包。有些版本的构建脚本还支持直接嵌入 Tomcat 运行，但生产环境我建议还是部署到独立的 Tomcat 里，便于管理。

7.2 数据库初始化与配置

切 MySQL 模式的核心步骤如下：

第一步，创建数据库：

CREATE DATABASE shepherd CHARACTER SET utf8 COLLATE utf8_general_ci;

第二步，执行项目提供的初始化脚本（一般在源码的db或sql目录下）。

第三步，修改 JDBC 连接配置。把驱动类改为com.mysql.cj.jdbc.Driver，连接串改为：

jdbc:mysql://localhost:3306/shepherd?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

第四步，确认 MySQL 账号有足够的权限。实际操作中，我不建议直接用 root，而是创建一个独立账号，只授予shepherd库的全部权限。

7.3 Tomcat 部署与启动

将 WAR 包复制到 Tomcat 的webapps/目录：

cp target/security-shepherd.war /opt/tomcat/webapps/

启动 Tomcat：

/opt/tomcat/bin/startup.sh

启动后访问：

http://你的服务器IP:8080/security-shepherd/

如果是本地测试，直接访问http://localhost:8080/security-shepherd/即可。

默认管理员账号通常在项目的 README 或初始化脚本里有说明，登录后第一件事，建议立刻修改默认密码，并创建真实的班级与学员账号。

7.4 部署中出现的高频报错处理

部署过程中最常见的报错有三类：

第一类是数据库连接失败。检查 MySQL 是否启动、账号密码是否正确、连接串是否写错。还有一种隐蔽原因：MySQL 8.x 默认认证插件是caching_sha2_password，老版本 JDBC 驱动不认识，导致连不上。解决方法是换新驱动，或者把用户认证插件改回mysql_native_password。

第二类是中文乱码。这个和前面提到的字符集参数有关。如果已经启动后才发现乱码，修改连接串再重启基本能解决。但如果建库时字符集没设对，可能需要重新建库导数据。

第三类是端口冲突。服务器上如果已经装了其他应用占用 8080，要么换 Tomcat 端口，要么关掉冲突服务。改端口在 Tomcat 的conf/server.xml里改<Connector>配置即可。

8. 常见问题与踩坑记录

在实际使用这套系统的过程中，我积累了一些典型的踩坑经验，这里整理成问题速查表，方便你排查。

还有一个隐蔽问题：当学员数量较多、并发访问较高时，默认的 H2 内存模式会偶发锁表异常。这就是为什么正式培训一定要切换 MySQL。我见过有人用 H2 模式撑了 30 个并发学员，结果一天之内系统卡死两次，彻底影响了培训节奏。

另外，如果你打算让学员在培训结束后继续访问系统，建议做定时备份。我通常用 crontab 每天凌晨备份 MySQL 数据库，这样即使出现误删数据或服务器故障，也能恢复到前一天的状态。

9. 扩展与改造建议

如果你已经跑通了基础功能，接下来就可以考虑基于这套系统做二次扩展。以下三个方向是我认为最有价值的改造点。

9.1 自定义新增训练关卡

在源码的关卡目录下添加一个新的 JSP 页面，然后在数据库的关卡表中插入一条记录，配置好分类、难度、积分。核心是要保证新关卡能接入现有的授权校验和积分奖励逻辑。

这里有一个容易踩的坑：新页面的 URL 路径必须和数据库记录严格一致，否则授权校验过不了，学员点进来会被拦截。我建议在添加关卡前，先分析一个现有关卡的表记录和页面路径，照葫芦画瓢来做。

9.2 与现有教学系统对接

如果你所在的组织已经有学习管理系统（LMS），可以考虑做账号同步。最简单的方案是用 Python 脚本定时读取某系统的学员名单，通过调用 SecurityShepherd 的注册接口批量创建账号。没有现成接口的情况下，可以直接操作数据库插入用户记录，但要注意密码加密方式和默认角色的字段值。

9.3 引入自动化评分评估

默认的积分规则比较固定，如果希望考核维度更丰富，可以在积分记录表中新增字段，记录每题/每关的得分能力维度和耗时，后台按维度聚合成“能力雷达图”。这个改动不算伤筋动骨，但能明显提升教学管理的颗粒度。

我在实际改造中，把原先的“总分排行榜”页面改成了“分类能力矩阵图”，把 SQL 注入、XSS、CSRF 等类别的得分分别展示，学员对自己的短板一目了然。这个改动在培训反馈中收到了非常好的评价。

10. 写在最后的个人心得

SecurityShepherd 这套系统，我最认可的地方不是某一个漏洞实现得有多精妙，而是它把“训练”这件事做成了一条完整的管理链条。从关卡授权、积分累积、排名反馈到后台跟踪，每一个环节都在为“提升教学效果”服务。

在实际部署和使用中，我最大的体会是：这类系统不怕“老”，就怕“乱”。它的技术栈朴实无华，但结构清晰、数据模型完整，反而比一些花哨的现代靶场更容易落地。如果你正在为团队或学校选型安全训练平台，又想拥有完整的考核数据闭环，SecurityShepherd 绝对值得在虚拟机里跑起来试一轮。

最后再分享一个小技巧：在训练开始前，先把所有关卡的答案源码全部浏览一遍，确认每个关卡的过关判定逻辑清晰可执行。这样能有效避免学员在训练过程中因为某个关卡判定失效而卡住，进而影响整堂课的节奏。磨刀不误砍柴工，这套系统的上限很高，但前提是你自己先把每个关卡都亲手打通一遍。