开源安全软件工程实践分析——结对练习2：OWASP ZAP 主动扫描模块深度解析

引言

在本次结对练习中，我们选择了全球知名的Web安全漏洞扫描工具——OWASP ZAP (Zed Attack Proxy) 的核心模块进行精读分析。ZAP作为开源安全领域的标杆项目，其主动扫描模块的设计与实现具有极高的学习价值。

本文将从模块选型、架构复原、代码标注、质量审查、协作反思五个维度，系统性地呈现我们对 org.zaproxy.zap.extension.ascan 与 org.parosproxy.paros.core.scanner 模块的精读成果。

一、模块选型说明

项目名称	OWASP ZAP (Zed Attack Proxy)
模块路径	org.zaproxy.zap.extension.ascan org.parosproxy.paros.core.scanner
代码行数	核心架构约 3500 行（含 HostProcess、ActiveScan、Scanner 及插件工厂等）
选择理由	主动扫描是 ZAP 最核心的业务场景，运用了典型的插件化架构和多线程消费池模式。理解此模块对于掌握漏洞扫描引擎的核心调度逻辑、理解漏扫请求从发起到漏洞判定的完整生命周期至关重要。

二、任务1：详细设计复原——顺序图与类图

2.1 顺序图（核心业务流程）

场景描述：用户触发某个节点的主动扫描任务 → 扫描器执行并发现漏洞 → 输出安全告警（Alert）

流程说明：

1. ActiveScan 接到任务后，启动独立工作线程 HostProcess
2. HostProcess 分析目标树（Node），调用 PluginFactory 加载待执行的漏洞检测插件
3. Plugin 生成测试请求，由 HttpSender 执行网络发包并接收 HTTP Response
4. Plugin 通过解析 Response 判断漏洞存在性，存在则通过回调 HostProcess 挂载 Alert 并通知 UI 更新

2.2 类图（核心类结构与设计模式）

设计模式	应用位置	说明
工厂模式	PluginFactory	批量实例化基于 AbstractPlugin 的各类漏洞检测插件
策略模式	插件调度与网络请求逻辑解耦	每个插件封装独立的检测策略，运行时动态选择
观察者模式	ScannerListener 事件体系	扫描进度、告警产生等事件通过监听器异步通知

核心类关系：

• ActiveScan：扫描控制器，管理多个 HostProcess
• HostProcess：单主机扫描线程，调度插件执行
• AbstractPlugin：插件基类，各漏洞检测插件继承实现
• PluginFactory：插件实例工厂
  

三、任务2：代码标注——隐性知识显性化

函数1：HostProcess.run() —— 核心调度流

文件：HostProcess.java

主要功能：作为线程的核心执行体，负责驱动针对单一 Host 主机的全量主动扫描调度操作。

核心实现思路：

• 通过 traverse() 遍历收集待测试的 NodeToScan
• 使用 while (!isStop() && pluginFactory.existPluginToRun()) 轮询加载新插件
• 执行 processPlugin(plugin) 交由线程池并发执行发包检测

复杂度分析：

• 时间复杂度：O(P × M)，P 为插件数量，M 为待测端点数量
• 性能瓶颈：线程池配置过小时，大量阻塞的 HttpSender 会导致 HostProcess 积压卡死
  
  
  

函数2：HostProcess.spanMessage(Plugin plugin, int messageId)

文件：HostProcess.java

主要功能：对单一 HTTP 请求使用指定漏洞规则进行扫描发包测试。

核心实现思路：

• 利用反射 plugin.getClass().getDeclaredConstructor().newInstance() 动态生成每个测试对应的 Plugin 实例（确保多线程隔离安全）
• 线程池满时，采用 while(thread == null) { Util.sleep(200); } 自旋轮询等待

设计权衡：自旋等待虽能限流，但牺牲了部分 CPU 时间，避免了复杂线程协同组件的引入。

函数3：HostProcess.traverse(StructuralNode node, ...)

文件：HostProcess.java

主要功能：递归遍历 ZAP 的历史记录树节点，筛选符合 Scope 要求的节点压入执行队列。

核心实现思路：深度优先搜索（DFS）递归遍历，判断 canScanNode(node) 验证节点是否在作用域内。

潜在缺陷：超深层级（如上万级子目录）可能触发 StackOverflowError。

函数4：ActiveScan.start(Target target)

文件：ActiveScan.java

主要功能：主动扫描器的控制引擎入口，负责拉起工作线程并监控扫描进度。

核心实现思路：

• super.start(target) 创建对应域名的多个 HostProcess 线程
• 利用 ScheduledExecutorService 创建周期任务（period = 2），通过求差法计算扫描进展并存入缓存

优点：采用拉模式（Pull）更新 UI，而非推模式（Push），极大降低了 Swing 界面的负载卡顿。

函数5：ActiveScan.notifyNewMessage(final HttpMessage msg)

文件：ActiveScan.java

主要功能：网络请求返回的公共回调钩子，记录临时扫描消息并分发给模型表。

核心实现思路：

• 判断是否需要 persistTemporaryMessages，需要则存入数据库
• 调用 EventQueue.invokeLater(...) 将显示更新操作转交给 GUI 主线程
• 通过 this.rcTotals.getTotal() > this.maxResultsToList 进行限流
  
  

四、任务3：代码质量分析与审查

4.1 工具分析结果

告警1：序列化类未使用 @Serial 注解

• 位置：ActiveScanPanel.java:59 private static final long serialVersionUID = 1L;
• 类型：代码规范/易维护性
• 分析：Java 14+ 引入 @Serial 注解，添加后可让编译器提前校验，提高可读性与健壮性
• 修改建议：
  

@Serial
private static final long serialVersionUID = 1L;

告警2：错误地在 StringBuilder.append() 中使用 + 拼接

• 位置：ActiveScanAPI.java:1263 sb.append("<h2>" + this.getName() + "</h2>\n");
• 类型：性能问题
• 分析：使用 StringBuilder 本意是避免对象频繁创建，但内部 + 会额外创建隐匿的 StringBuilder 副本，违背优化初衷
• 修改建议：
  

sb.append("<h2>").append(this.getName()).append("</h2>\n");

告警3：调用不必要的 .toString() 方法

• 位置：Analyser.java:317 sb.append(newUri.toString());
• 类型：代码冗余
• 分析：StringBuilder.append(Object) 底层会自动调用 String.valueOf(obj)，无需显式 toString()
• 修改建议：

sb.append(newUri);

4.2 人工审查

维度一：异常处理

实例1（处理缺陷）：

catch (HttpMalformedHeaderException | DatabaseException e) {
    LOGGER.warn("Failed to read message with ID [{}], cause: {}", messageId, e.getMessage());
    return false;
}

• 问题：仅保留 e.getMessage()，丢失完整堆栈信息
• 改进：直接传入 e 对象 LOGGER.warn("Failed to read message with ID [{}]", messageId, e);
• 

实例2（设计亮点）：

catch (HttpMalformedHeaderException | DatabaseException e) {
    if (ErrorUtils.handleDiskSpaceException(e)) {
        this.getHostProcesses().forEach(HostProcess::stop);
        return;
    }
}

• 亮点：磁盘空间不足时，直接全局停止扫描，避免无穷重试和二次崩溃
  

维度二：可读性与风格

实例1：变量命名过度缩写

• rcTotals、hRefs → 应改为 responseCountTotals、historyReferences
  

实例2：链式判断语义晦涩

boolean isLowOrderPath() {
    return path == null || path.isEmpty() || path.charAt(path.length() - 1) != '/';
}

• 改进：抽取中间变量，提升自解释性

boolean isRootOrDirectory = (path != null && !path.isEmpty() && path.endsWith("/"));
return !isRootOrDirectory;

维度三：性能效率

实例1：自旋轮询等待

• 建议改用 BlockingQueue 实现生产者消费者模型，避免无效 CPU 消耗
  

实例2：UI 逐条刷新

• 高并发场景下，每一条消息都通过 EventQueue.invokeLater 发送到 EDT，易造成界面卡顿
• 建议改为 500ms 批量合并处理
  

五、任务4：结对过程记录与协作效果评估

5.1 分工描述

本次结对严格遵循**领航员-驾驶员（Navigator-Driver）**协作模式：

子任务	驾驶员	领航员	分工说明
UML 建模	林源龙	刘振求	梳理调用关系、绘制 UML 图，实时核对与时序
核心代码标注	刘振求	林源龙	逐行注释、提炼逻辑，校验准确性
静态代码分析	林源龙	刘振求	运行工具、导出报告，验证告警有效性
人工代码审查	共同	共同	从异常处理、安全编码、性能效率提出优化点
报告整合	刘振求	林源龙	整理内容格式，审核完整性规范性

5.2 协作感受

• 精读对底层功底要求极高：多线程、JUC、异常层级等概念需要深入理解
• 1+1 > 2 的效果明显：在 Util.sleep(200) 的审查中，一人认为常见不需修改，另一人从高并发角度分析损耗，推导出队列优化方案
• 遇到的障碍：代码层级深、交叉依赖复杂。解决方案：边读边画序列图，先抓骨架再填血肉

---

结语

通过本次结对精读，我们不仅深入理解了 OWASP ZAP 主动扫描模块的架构设计与实现细节，更在实践中提升了代码审查能力、协作效率与技术表达能力。开源项目的精读不是简单的“看代码”，而是通过“代码+设计+质量”三个维度的立体分析，真正将隐性知识显性化。

如果你也对开源安全工具感兴趣，不妨从 ZAP 开始，开启你的精读之旅！ 🔍