WPScan 插件版本识别实战：从 Token of Trust CHANGELOG 看动态查找器（Dynamic Finders）如何提取插件版本

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI

【免费下载链接】wpscan

WPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via [e-mail]

项目地址：https://gitcode.com/gh_mirrors/wp/wpscan

点击查看免费下载

导读

本文以 WPScan 仓库中一份真实插件变更日志——Token of Trust 的 CHANGELOG.md 为主线，系统解读该 WordPress 插件从 0.0.1 到 1.3.4 的功能演进（用户审核、邮箱验证、BuddyPress/Ultimate Member 集成、Live/Test 模式、SSL 检测等），并深入剖析这份 CHANGELOG 在 WPScan 安全扫描器中的真实用途：它是插件版本动态查找器（Dynamic Finders）体系的测试夹具（fixture），用于验证 WPScan 能从插件的 changelog 文件中准确匹配出版本号。读完本文，你将掌握 Token of Trust 插件的核心能力全貌，同时理解 WPScan 基于dynamic_finders.yml配置文件驱动、运行时动态生成版本查找类、并通过 changelog 等文件指纹识别插件版本的底层原理。

一、关联文档定位：一份 CHANGELOG 在安全扫描器中的角色

WPScan 是面向安全专业人员与博客维护者的 WordPress 安全扫描器，其核心能力之一是在不访问 WordPress 后台的情况下，通过公开可访问的文件指纹识别站点上已安装插件及其精确版本，进而匹配已知漏洞。

本文的主角是仓库中的 spec/fixtures/dynamic_finders/plugin_version/token-of-trust/change_log/CHANGELOG.md。它记录的是一款名为Token of Trust的 WordPress 插件（用于身份验证与信任标记）的完整变更历史。该文件被放在 WPScan 的测试夹具目录下，目录路径本身已经说明了它在项目中的定位：

spec/fixtures/dynamic_finders/ ├── plugin_version/ # 插件版本查找器测试夹具 │ └── token-of-trust/ │ └── change_log/ │ └── CHANGELOG.md # 本文关联文档 ├── theme_version/ # 主题版本查找器测试夹具 ├── wp_version/ # WordPress 核心版本查找器测试夹具 └── expected.yml # 各夹具对应的期望识别结果

从目录结构可以推断，WPScan 为插件、主题和 WordPress 核心分别维护了一套「版本动态查找器」测试体系：将真实站点上可能存在的文件（如插件的change_log/CHANGELOG.md、readme.txt、样式表等）作为夹具，再通过expected.yml声明这些夹具应当被识别出的版本与置信度，以此验证查找器的正确性。也就是说，这份 changelog 既是插件自身的产品历史文档，也是 WPScan 插件版本识别能力的一项可复现测试数据。

二、Token of Trust 插件功能演进全解读（0.0.1 → 1.3.4）

原 CHANGELOG 从 0.0.1 到 1.3.4 记录了该插件两年多的演进过程。下面按版本逐条完整还原，并按功能主题归纳其技术脉络。

2.1 初始版本：0.0.1 – 0.0.5（基础能力与 API 对接）

插件最初（0.0.1）仅具备三块基础能力：

• 设置页面（Settings Page）：在 WordPress 后台提供插件配置入口；
• WordPress 管理后台集成（admin dashboard integration）：将插件状态融入后台管理界面；
• BuddyPress 集成：与社交社区插件 [BuddyPress] 打通。

随后几个迭代集中在 API 与连接链路的打磨上：

• 0.0.2：正式加入 UltimateMember（UM）集成，并增加插件徽标在 UM 标签页的尺寸适配（0.0.3 中进一步为默认样式加入 Token of Trust 部件背景）；
• 0.0.3：完善默认样式中的部件背景与 UM 标签页图标尺寸；
• 0.0.4：开始使用许可证密钥（license keys）取代旧的激活方式，引入能力检查（capability checks）、**调试模式（debug mode）**以及错误详情页的错误处理；
• 0.0.5：按 API 规范更新「set connection（建立连接）」端点，并补充该端点的错误上报。

2.2 走向可用：1.0.x（生产域测试、后台部件与端口检查）

1.0.0 标志着插件正式发布到 WordPress 插件市场（marketplace），此后的 1.0.x 系列快速补全了运行细节：

• 1.0.1：允许在正式 live 密钥签发之前，把生产域名当作测试环境使用——这是测试环境搭建上的关键灵活性；
• 1.0.2：将 Token of Trust 部件接入 WordPress 用户管理后台界面（User administration screens），并对 API 连接做小幅增强；
• 1.0.3：修正 UltimateMember 个人资料页中账户连接器（account connector）的展示问题；
• 1.0.4：增强 UltimateMember 的调试能力；
• 1.0.5：修复 API 连接检查逻辑（改用客户端主机进行检测）、为 localhost 增加端口检查并给出「仅支持特定端口」的明确警告，同时补充短代码（shortcodes）的文档。

可以看到，1.0.x 系列的核心是把「生产可用性」补全：测试/生产环境的边界、SSL/端口等网络层面的健壮性，以及对 BuddyPress、UltimateMember 两大社区插件的深度适配。

2.3 集成与通知：1.1.x（邮箱验证、SSL、迁移与短代码）

1.1.x 系列是功能密度最高的一个阶段：

• 1.1.1：增强 BuddyPress 调试；支持将 Token of Trust 部件连接到自定义用户 GUID；新增数据库迁移脚本；
• 1.1.2：在插件列表页增加设置入口（settings link），并在管理后台 UI 中加入激活与许可证相关的通知；
• 1.1.3：为通知提供降级版布局（fallback notice layout）；
• 1.1.4：优化通知（notice）体验；
• 1.1.5：增强文档，并改进 SSL 检查；
• 1.1.6：实现自动 SSL 配置，修复包括 live 模式域名在内的小问题；
• 1.1.7：为verifiedIndicator部件短代码增加「未验证（not verified）」状态展示；
• 1.1.8：新增**邮箱验证（email verification）**功能，加入「Getting Started」引导，并在用户管理页签上标记未验证状态；
• 1.1.9：澄清插件描述，并针对 WordPress 4.9.1 完成兼容性测试；
• 1.1.10：加入 UltimateMember 与 BuddyPress 设置项；在 UM 账户页增加**已验证标识（verified indicator）**与账户连接器，并优化调试输出。

这一阶段可以概括为「三线并进」：身份验证链路（邮箱验证、已验证标识、未验证状态）、部署健壮性（SSL 自动配置、live/测试域名处理）、以及两大社区插件的 UI 集成。

2.4 审核与报表：1.2.x（滥用举报与用户审核白名单）

1.2.0 是该插件产品定位的重要转折——从「身份标记」扩展为「社区治理」：

• 1.2.0：新增**向 WordPress 管理员举报滥用（report abuse）**的能力，提供「自动把该能力附加到 UltimateMember 与 BuddyPress」的设置项，管理员也可在 WordPress 后台的用户管理界面直接提交举报；
• 1.2.1：增加对Ultimate Member 2的支持，并针对最新版 WordPress 与 BuddyPress 进行回归测试；
• 1.2.2：更新账户管理相关的链接与文案；
• 1.2.3：兼容PHP < 5.5；
• 1.2.4：增强对测试模式（test mode）的控制。

2.5 成熟期：1.3.x（用户审批、角色联动与简化 live 流程）

1.3.x 是该插件的成熟形态，也恰好是 CHANGELOG 的收尾版本：

• 1.3.0（2018-06-21 发布）：新增**用户审批（user approval / 白名单）**机制，并更新邮箱确认（email confirmation）的展示方式；
• 1.3.1（2018-07-15 发布）：当用户审批状态变化时自动分配角色（automatically assign roles）；更好地处理 live/测试域名；附带若干 bug 修复；
• 1.3.2：新增用于向 Token of Trust「set connection」端点发送额外appData的action hook；通过 API 更新用户连接信息与附加信息；附带若干 bug 修复；
• 1.3.3：支持以 WordPress 管理员的审批决定覆盖（override）Token of Trust 的验证状态；改进 live 模式检测；简化 live 模式的流程与设置界面；
• 1.3.4：支持 WordPress 5.0.1。

2.6 演进脉络速览

阶段	版本区间	主题关键词
起步	0.0.1 – 0.0.5	设置页、后台集成、BuddyPress/UM 集成、许可证密钥、set connection 端点
可用化	1.0.0 – 1.0.5	插件市场发布、后台部件、localhost 端口检查、生产域作测试域
集成爆发	1.1.1 – 1.1.10	邮箱验证、SSL 自动配置、已验证标识、迁移脚本、Getting Started
社区治理	1.2.0 – 1.2.4	滥用举报、UM 2 支持、PHP < 5.5 兼容、测试模式控制
成熟	1.3.0 – 1.3.4	用户审批白名单、角色自动联动、appDataaction hook、管理员覆盖审批、WP 5.0.1 支持

三、WPScan 侧实现原理：动态查找器如何利用这类文件识别版本

理解了 changelog 的内容，再看 WPScan 是怎么「消费」它的。WPScan 的插件版本识别并不为每个插件手写探测代码，而是采用一套配置驱动、运行时动态生成类的「动态查找器（Dynamic Finders）」体系。

3.1 配置中枢：dynamic_finders.yml

所有插件/主题/WordPress 的版本查找规则集中存放在一份名为dynamic_finders.yml的数据库文件中。从 lib/wpscan/db/dynamic_finders/base.rb 可以看到其加载逻辑：

def self.df_file @df_file ||= DB_DIR.join('dynamic_finders.yml') end def self.all_df_data @all_df_data ||= YAML.safe_load_file(df_file, permitted_classes: [Regexp]) end

该文件同时界定了动态查找器允许使用的查找类（allowed_classes），包括Comment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParser（见 base.rb）。每一种类都对应一种「从页面/文件里提取版本」的探测方式：

查找器类	探测方式	默认置信度
Comment	扫描页面 HTML 注释（默认 XPath//comment()）	60
Xpath	按 XPath 定位节点后用正则匹配	60
HeaderPattern	匹配响应头（如Etag、WP-Version）	60
BodyPattern	匹配页面正文内容	由配置决定
JavascriptVar	在脚本节点中匹配 JS 变量	由配置决定
QueryParameter	匹配静态资源 URL 的?ver=查询参数	由配置决定
ConfigParser	解析配置文件（如 PHP 常量）	由配置决定

以仓库中的真实配置为例（spec/fixtures/db/dynamic_finders.yml）：

MetaGenerator: class: Xpath xpath: //meta[@name="generator"]/@content pattern: !ruby/regexp /wordPress (?<v>\d+\.[\.\d]+)/i version: true

配置中pattern里以命名捕获组(?<v>...)标记的「版本号」会被提取为插件版本；version: true表示该查找器用于版本识别。每个插件的slug是配置的一级键，WPScan 会依据 slug 在运行时动态创建对应的查找类。

3.2 运行时动态生成查找类

插件动态查找器的核心实现在 lib/wpscan/db/dynamic_finders/plugin.rb。其工作流程为：

1. df_data（L8-L10）从all_df_data['plugins']中取出全部插件配置；
2. versions_finders_configs（L46-L61）筛出所有带version键的查找配置；
3. maybe_create_module(slug)（L65-L74）把插件 slug（如token-of-trust）转换为常量名（如TokenOfTrust），并在WPScan::Finders::PluginVersion命名空间下创建模块；
4. create_versions_finders(slug)（L81-L103）为配置中的每个查找器调用对应父类的create_child_class，动态生成具体的查找类。

值得注意的设计（见 plugin.rb 中的注释）：当dynamic_finders.yml引入了新查找器而用户仍在使用旧版 WPScan 时，代码会跳过不支持的查找器而不是抛出异常，保证旧版工具配合新版数据库仍能完成扫描。

3.3 版本查找器的具体匹配逻辑

以 changelog 类文件最常用的Comment/Xpath查找器为例：

• version/comment.rb 本质上是 Xpath 查找器，但默认 XPath 固定为//comment()，即把整个文档视为注释节点集合；
• version/xpath.rb 定义了默认版本正则\A(?<v>\d+\.[.\d]+)与默认置信度 60；find方法通过xpath_pattern_from_page在页面中按 XPath 定位并用正则匹配，命中后把捕获的match_data[:v]封装为Model::Version，同时记录interesting_entries（含命中的 URL 与匹配串）；
• version/header_pattern.rb 则从响应头中取值并做正则匹配。

也就是说，一份像change_log/CHANGELOG.md这样的文件（其中包含## 1.3.4这类版本标题），正是Comment/Xpath类查找器通过「在文件中匹配(?<v>\d+\.\d+...)模式的版本号」完成识别的理想样本——这也解释了为什么 WPScan 需要把这类 changelog 归档为测试夹具。

3.4 数据更新与测试保障

• 数据来源：dynamic_finders.yml与metadata.json、wp_fingerprints.json等文件一起，由 WPScan 的数据库更新器从data.wpscan.org同步，见 lib/wpscan/db/updater.rb 中的FILES列表；
• 测试验证：spec/lib/db/dynamic_finders/plugin_spec.rb 验证了finder_configs在 passive（无path参数）与 aggressive（有path参数）两种模式下的筛选行为，以及 slug 转模块名的分类逻辑（如123-test-plugin→D_123TestPlugin，见该文件 L81-L91）。而spec/fixtures/dynamic_finders/expected.yml则声明了各夹具（包括本文的 token-of-trust changelog）应当被识别出的版本结果。

四、如何在仓库中查看与复现

若想亲自验证 WPScan 的 ChangeLog 版本识别链路，可按以下步骤在仓库内查看：

1. 查看夹具：打开 spec/fixtures/dynamic_finders/plugin_version/token-of-trust/change_log/CHANGELOG.md，观察其以## 版本号为标题的结构——这正是版本查找器要匹配的目标文本形态；
2. 查看期望结果：阅读 spec/fixtures/dynamic_finders/expected.yml，确认token-of-trust各查找器应当返回的版本与置信度声明；
3. 阅读驱动逻辑：对照 lib/wpscan/db/dynamic_finders/plugin.rb 与 lib/wpscan/finders/dynamic_finder/version/xpath.rb 理解「配置 → 动态建类 → 正则提取版本」的完整链路；
4. 运行相关测试：仓库中与插件动态查找器相关的测试集中在 spec/lib/db/dynamic_finders/plugin_spec.rb 与 spec/lib/finders/dynamic_finder 目录下，可配合 RSpec 执行验证。

五、总结

Token of Trust 插件的 CHANGELOG 本身是一部完整的「产品演进史」：从 0.0.1 的设置页与 BuddyPress 集成起步，历经许可证密钥（0.0.4）、邮箱验证与 SSL 自动配置（1.1.x）、滥用举报与用户审核白名单（1.2.x/1.3.x），最终形成「身份验证 + 社区治理」的完整形态。而在 WPScan 仓库中，这份 changelog 承担了更具体的工程职责——作为插件版本动态查找器的测试夹具，与dynamic_finders.yml配置、动态生成的查找类以及expected.yml期望声明一起，构成了「基于公开文件指纹识别插件版本」这一安全扫描能力的可复现证据链。理解这一体系，也就掌握了 WPScan 插件识别模块从数据到代码再到测试的全貌。

赞分享

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI

【免费下载链接】wpscan

WPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via [e-mail]

项目地址：https://gitcode.com/gh_mirrors/wp/wpscan

点击查看免费下载

相关推荐

• WPScan 插件版本探测实战：ChangeLog 动态查找器（Dynamic Finders）原理与 Fixture 体系解析

  WPScan 插件版本探测实战：ChangeLog 动态查找器（Dynamic Finders）原理与 Fixture 体系解析 本文以 WPScan 仓库中

  网络安全漏洞扫描渗透测试应用安全CLI

• WPScan 插件版本指纹实战：从 Media Credit 的 CHANGELOG.md 看动态查找器如何识别插件版本

  WPScan 插件版本指纹实战：从 Media Credit 的 CHANGELOG.md 看动态查找器如何识别插件版本 本文以 WPScan 仓库中的 Wor

  网络安全漏洞扫描渗透测试应用安全CLI

• WPScan 插件版本识别实战：用 CHANGELOG.md 动态查找器（Dynamic Finder）锁定 rest-manager 插件版本

  WPScan 插件版本识别实战：用 CHANGELOG.md 动态查找器（Dynamic Finder）锁定 rest manager 插件版本 导读 本文以

  网络安全漏洞扫描渗透测试应用安全CLI

上一篇：A2UI事件系统详解：处理用户交互的最佳实践

下一篇：开源突破！WebRL-GLM-4-9B实现网页代理43%成功率，超越GPT-4系列