企业官网建设流程全解析

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

导读

WPScan 是面向安全从业者与 WordPress 站点维护者的 WordPress 安全扫描器。本文以 login-customizer 插件的 CHANGELOG.md 指纹样本 为切入对象，剖析 WPScan 如何通过读取插件随包分发的变更记录（ChangeLog）来精准识别插件版本号。读完本文，你将理解动态指纹库（Dynamic Finders）的目录约定、ChangeLog 指纹的数据形态、ChangeLog版本探测器的源码实现与实例化流程，以及指纹库的测试验证方式，并能在自己的 WPScan 实战扫描中定位与利用这类指纹。

从一份变更记录说起：ChangeLog 为何能成为版本指纹

登录 WordPress 后台时看到的登录页定制能力，通常由 "Login Customizer" 这类插件提供。这类插件在源码包中往往附带一份CHANGELOG.md，按时间倒序记录每个版本的改动。对扫描器而言，这份文件有两重价值：

1. 位置稳定：插件目录结构相对固定，CHANGELOG.md常随插件一起分发，可被请求并读回正文；
2. 语义明确：文件内以### v1.2.1 - 2018-01-05这类标题逐条记录版本，格式可被规则化匹配。

因此 WPScan 将此类文件收录为"插件版本动态指纹"：只要目标站点仍暴露着未被删除的CHANGELOG.md，扫描器就能在不依赖官方版本库的情况下直接判定插件版本。

指纹数据的目录约定：change_log 目录与 CHANGELOG.md 文件

在 WPScan 仓库中，所有插件动态指纹样本统一存放在 spec/fixtures/dynamic_finders/plugin_version/ 下，每个插件 slug 一个子目录。以 login-customizer 为例，目录结构为：

spec/fixtures/dynamic_finders/plugin_version/ └── login-customizer/ └── change_log/ └── CHANGELOG.md

这里的目录名change_log直接对应探测器的类别名（ChangeLog），文件名CHANGELOG.md则是该插件实际分发时使用的变更记录文件名。WPScan 约定：只要某个 finder 配置里存在version键，且请求路径命中该文件，就依据文件内容匹配版本号（对应逻辑见 lib/wpscan/db/dynamic_finders/plugin.rb 中versions_finders_configs对含version键配置的收集）。

样本文件内容节选如下（完整内容见 login-customizer/change_log/CHANGELOG.md）：

### v1.2.1 - 2018-01-05 **Changes:** * Improves compatiblity with latest WordPress version. * Sync ThemeIsle SDK. ### v1.2.0 - 2017-10-16 **Changes:** * Adds tested up to wp 4.8. * Improvements to dashboard widget, rollback. ### 1.1.0 - 19/01/2017 **Changes:** - Added dashboard widget ### 1.0.8 - 27/10/2016 **Changes:** - Removed notification script ...

可以看到，该插件的变更记录横跨 2015 年至 2018 年（v1.0.2 → v1.2.1），并且存在两个值得注意的样本特征：

• 格式演进：早期条目使用### 1.0.8 - 27/10/2016，后期条目使用### v1.2.1 - 2018-01-05，版本号前缀v与日期格式并不统一，这对指纹正则的鲁棒性提出了要求；
• 重复条目：1.0.2 - 23/06/2015出现了两次，说明真实插件的变更记录可能存在内容冗余，指纹匹配时应容忍重复。

ChangeLog 指纹在 WPScan 架构中的位置

WPScan 的动态版本指纹体系分为两层：配置收集层与探测器生成层。

配置收集层：versions_finders_configs

lib/wpscan/db/dynamic_finders/plugin.rb 中的versions_finders_configs遍历插件指纹数据（df_data），只保留含version键的 finder 配置，并按插件 slug 聚合：

@versions_finders_configs = {} df_data.each do |slug, finders| finders.each do |finder_name, config| next unless config.key?('version') @versions_finders_configs[slug] ||= {} @versions_finders_configs[slug][finder_name] = config end end

从源码结构看，一个插件可以同时拥有多个版本探测器（如 ChangeLog、Readme 等），WPScan 会在扫描时逐一尝试，命中任意一个即可确定版本。

探测器生成层：WpItemVersion 模块与 ChangeLog 子类

lib/wpscan/finders/dynamic_finder/wp_item_version.rb 定义了插件/主题版本探测器的统一基类集合：

module WPScan module Finders module DynamicFinder module WpItemVersion class BodyPattern < Finders::DynamicFinder::Version::BodyPattern end class Comment < Finders::DynamicFinder::Version::Comment end class ConfigParser < Finders::DynamicFinder::Version::ConfigParser end class HeaderPattern < Finders::DynamicFinder::Version::HeaderPattern end class JavascriptVar < Finders::DynamicFinder::Version::JavascriptVar end class QueryParameter < Finders::DynamicFinder::Version::QueryParameter ... end class Xpath < Finders::DynamicFinder::Version::Xpath end end end end end

而 lib/wpscan/db/dynamic_finders/plugin.rb 中的create_versions_finders(slug)则负责运行时动态生成针对特定插件的探测器子类：

def self.create_versions_finders(slug) created = [] mod = maybe_create_module(slug) versions_finders_configs[slug]&.each do |finder_class, config| klass = config['class'] || finder_class next unless allowed_classes.include?(klass.to_sym) created << if mod.const_defined?(finder_class.to_sym, false) mod.const_get(finder_class.to_sym) else version_finder_super_class(klass).create_child_class(mod, finder_class.to_sym, config) end end created end

对 login-customizer 而言，finder_class即ChangeLog，其父类解析路径为WPScan::Finders::DynamicFinder::WpItemVersion::ChangeLog，最终由version_finder_super_class完成常量解析（见 plugin.rb）。

版本结果的统一封装

所有版本探测器都继承自 lib/wpscan/finders/dynamic_finder/version/finder.rb，其中create_version负责把匹配到的字符串统一封装为Model::Version，并附带found_by（来源标记）与confidence（置信度）：

def create_version(number, finding_opts) Model::Version.new(number, version_finding_opts(finding_opts)) end def version_finding_opts(opts) opts[:found_by] ||= found_by opts[:confidence] ||= self.class::CONFIDENCE opts end

这意味着无论版本号来自 ChangeLog 还是其他指纹，最终都以统一的Model::Version形式进入扫描报告，方便后续与漏洞库关联。

指纹的测试验证：expected.yml 回归基线

WPScan 使用 spec/fixtures/dynamic_finders/expected.yml 作为动态指纹的回归测试基线（该文件规模庞大，涵盖 WordPress 核心与大量插件/主题指纹）。每个条目记录探测结果、来源（found_by）与命中条目（interesting_entries），例如：

wordpress: AddthisJavascript: number: 3.8.1 found_by: Addthis Javascript (Passive Detection) interesting_entries: - 'http://wp.lab/, Match: ''wp_blog_version = "3.8.1";''' MostCommonWpIncludesQueryParameterInHomepage: number: 3.8.1 found_by: Most Common Wp Includes Query Parameter In Homepage (Passive Detection) confidence: 100 interesting_entries: - http://wp.lab/wp-includes/js/wp-embed.min.js?ver=3.8.1 ...

其机制是：使用仓库内的 HTTP 测试环境（fixtures 模拟的站点响应）驱动 finder 运行，将实际探测出的number、found_by与基线逐条比对。一旦指纹配置的路径、正则或置信度被改动而破坏匹配，测试即失败。ChangeLog 指纹样本因此也必须保证：从样本文件正文中能稳定解析出插件真实存在的版本号（如1.2.1），且解析出的found_by值符合ChangeLog探测器约定。这正是 login-customizer/change_log/CHANGELOG.md 这份样本存在意义的落地验证。

实战视角：如何观察与利用 ChangeLog 指纹

在扫描过程中定位指纹

当 WPScan 对目标站点执行插件版本探测时，ChangeLog探测器会请求插件目录下的变更记录文件（路径形如/wp-content/plugins/login-customizer/CHANGELOG.md）。你可以通过以下方式观察它的行为：

• 运行 WPScan 扫描并开启 verbose 输出，观察ChangeLog (Aggressive Detection)相关的请求日志；
• 当found_by字段出现 ChangeLog 时，报告中的插件版本条目即来源于本指纹。

指纹失效的常见原因

从样本特征可以推断，以下情况会导致 ChangeLog 指纹失效：

1. 文件被删除或改名：站点加固措施常移除CHANGELOG.md；
2. 文件可读但版本格式不匹配：样本中v1.2.1 - 2018-01-05与1.0.8 - 27/10/2016混用，若插件后续改用了完全不同的版本标注风格，旧正则将无法命中；
3. 插件更新但指纹库未同步：WPScan 的指纹数据随数据库更新（wpscan --update）同步刷新，旧版工具配旧库可能漏报新版本。

将本指纹用于人工审计

即使不运行扫描器，你也可以直接审计目标站点：

1. 请求https://<target>//wp-content/plugins/login-customizer/CHANGELOG.md（以实际站点路径为准）；
2. 检查返回的正文是否包含### v1.2.1 - 2018-01-05等版本标题；
3. 以解析出的版本号对照已知漏洞情报，判断该站点是否暴露了存在已知漏洞的插件版本。

小结

WPScan 的 ChangeLog 版本指纹是把"插件随包分发、内容可预测"的变更记录转化为自动化版本识别能力的典型实现。本文沿 login-customizer/change_log/CHANGELOG.md 样本，梳理了其数据形态（目录约定change_log/CHANGELOG.md、格式混用的版本标题）、架构位置（plugin.rb 的配置聚合与类动态生成、wp_item_version.rb 的基类体系、version/finder.rb 的版本封装）与验证机制（expected.yml 回归基线）。理解这条链路后，你既能读懂扫描报告中插件版本条目的来源，也能在实际扫描与加固中有的放矢地判断与处置暴露的 ChangeLog 文件。

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