尧图网页设计 
网络安全漏洞扫描渗透测试应用安全CLI【免费下载链接】wpscanWPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contactwpscan.com项目地址https://gitcode.com/gh_mirrors/wp/wpscan点击查看免费下载WPScan 是一款面向安全专业人员与 WordPress 站点维护者的 WordPress 安全扫描器。插件、主题的精确版本识别是后续漏洞匹配的基础而ChangeLog变更日志探测正是 WPScan Dynamic Finders 体系中一条成熟、高频的版本取证路径。本文以仓库中的真实样例 spec/fixtures/dynamic_finders/plugin_version/sticky-header-oceanwp/change_log/changelog.md 为具体实例完整还原 WPScan 如何从插件目录中一个 Markdown 格式的 changelog 文件出发通过配置文件、动态类生成、BodyPattern 匹配到最终版本号输出的完整链路并给出可复用的模式扩展方法。一、实例全景一条 ChangeLog 探测链路的完整数据流在开始阅读源码之前先围绕本文核心实例——sticky-header-oceanwp 插件的变更日志把 WPScan 中与它相关的三份关键数据串起来就能立刻看到整个机制的全貌。1. 源文件插件作者提供的变更日志spec/fixtures/dynamic_finders/plugin_version/sticky-header-oceanwp/change_log/changelog.md 是 WordPress 官方插件仓库中sticky-header-oceanwp插件作者随版本维护的 changelog 文件WPScan 将其作为测试 fixture 收录用于验证探测逻辑# Changelog ## [1.0.8] - 2021-10-22 ## Bug fix - Fixed bug support all oceanwp demo templates as well ## [1.0.7] - 2021-10-22 ### Support WordPress 5.8 - Supporting until the latest version of WordPress 5.8 - Fixed z-index issue, works with woocommerce quick previews as well. - Appreciate mdmosharofsk for helping solve the bug ## [1.0.6] - 2021-03-27 ### Support WordPress 5.7 - Supporting until latest version of WordPress 5.7 ### Changed - Changed the functions order on the main.js file - Fixed issue number #3 ## [1.0.5] - 2020-05-25 ### Origial version from wordpress repository - Oceanwp sticky header plugin publish / updated on wordpress plugins repository. ### Changed - Readme file fixed ### Added - Changelog file. - France translations (.mo/.po) files, Thanks to: momo-fr, Bruno Tritsch (btpub). ## [Unreleased] ## [1.0.5] - 2018-09-24这份文件有几个对探测机制至关重要的结构特征版本号以## [x.y.z]的 Markdown 二级标题形式出现且[与版本号之间没有空格这是本插件采用的固定格式文件以最高版本1.0.8开头、逐代向下排列符合最新版本置顶的常见 changelog 惯例存在重复版本号两个1.0.5与[Unreleased]占位段说明changelog 并非严格结构化的机器可读文件必须依赖精心设计的正则与取首个匹配策略才能得到可靠结果。2. 数据库配置WPScan 如何知道去哪里找、怎么找WPScan 将插件版本探测规则集中维护在数据库文件 spec/fixtures/db/dynamic_finders.yml 中生产运行时由wpscan --update从官方 DB 拉取同名规则lib/wpscan/db/dynamic_finders/base.rb 指向DB_DIR/dynamic_finders.yml。sticky-header-oceanwp的配置如下sticky-header-oceanwp: ChangeLog: class: BodyPattern path: changelog.md pattern: !ruby/regexp /\#\# \[(?v\d\.[\.\d])\]/ version: true逐字段解读字段取值含义ChangeLog探测器名称逻辑意义上的变更日志探测但真正的实现类由class决定classBodyPattern将实例化WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern类详见 lib/wpscan/finders/dynamic_finder/wp_item_version.rbpathchangelog.md攻击面探测路径http://目标/wp-content/plugins/sticky-header-oceanwp/changelog.mdpattern/\#\# \[(?v\d\.[\.\d])\]/正则命名捕获组v提取版本号\#\# \[精确锚定 Markdown 二级标题的## [前缀versiontrue标记这是一个版本探测型 finder而非文件名枚举型3. 期望结果测试断言锁定的探测结论spec/fixtures/dynamic_finders/expected.yml 中登记了该样例的期望输出等价于一条可自动回归验证的事实记录sticky-header-oceanwp: ChangeLog: number: 1.0.8 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/sticky-header-oceanwp/changelog.md, Match: ## [1.0.8]关键信息number: 1.0.8最终认定的插件版本是 changelog 中最新置顶的一个版本found_by: Change Log (Aggressive Detection)判定方式为 Aggressive主动请求指定路径而非 Passive仅分析首页/404 页响应interesting_entries记录命中的精确 URL 与匹配文本## [1.0.8]这是后续向用户展示版本由何而来的依据。注意测试环境中的http://wp.lab是 WPScan 测试套件使用的虚拟目标主机名见 spec/spec_helper.rb生产环境下会替换为真实被扫描站点的 URL。二、规则装载从 YAML 配置到动态 finder 类实例化配置数据本身不会自动变成可执行的探测代码WPScan 在扫描启动阶段完成配置 → 类的转换这一过程由 lib/wpscan/db/dynamic_finders/plugin.rb 承担。1. 配置读取与聚合Plugin Base通过df_data方法从dynamic_finders.yml中取出plugins顶层节点plugin.rb再由versions_finders_configs过滤出所有带version: true的条目plugin.rb。sticky-header-oceanwp的ChangeLog条目正是因为带有version: true才会进入版本探测候选集。2. 按 slug 动态建模块maybe_create_module把插件 slug 分类化为 Ruby 常量名并创建对应模块plugin.rbsticky-header-oceanwp→WPScan::Finders::PluginVersion::StickyHeaderOceanwp。随后create_versions_finders遍历该 slug 的版本探测配置为每个 finder 创建子类若模块中已存在同名常量如已被人手编写过 finder直接复用否则调用version_finder_super_class(klass).create_child_class(mod, finder_class.to_sym, config)动态生成plugin.rb。这里的klass即配置中的class: BodyPattern因此超类是WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern。3. 子类常量的注入机制动态生成的核心在 lib/wpscan/finders/dynamic_finder/finder.rb 的create_child_class它把配置中的path、pattern、confidence等键值对写入新建类的PATH、PATTERN、CONFIDENCE常量。对本实例而言生成后的类等价于class StickyHeaderOceanwp::ChangeLog PATH changelog.md PATTERN /\#\# \[(?v\d\.[\.\d])\]/ CONFIDENCE 60 # BodyPattern 默认置信度 end其中CONFIDENCE并非来自 YAML而是 body_pattern.rb 中定义的默认值 60配置未显式覆盖时即采用该值。三、探测执行Aggressive 模式下 BodyPattern 的匹配逻辑1. 主动探测的调度入口WpItemVersion::BodyPattern继承自通用动态 finder 基类finder.rb其aggressive方法在PATH存在时执行def aggressive(opts {}) return unless self.class::PATH find(Browser.get(target.url(self.class::PATH)), opts) end即PATH changelog.md存在因此走 aggressive 分支用浏览器组件请求target.url(changelog.md)。目标插件目录 URL 由Target#url基于wp-content/plugins/sticky-header-oceanwp/拼接插件目录前缀定义在扫描器配置中参见 lib/wpscan/target.rb 的相关方法。2. BodyPattern 的匹配与版本对象创建响应返回后进入 body_pattern.rb 的核心匹配def find(response, _opts {}) return unless response.code ! 404 response.body ~ self.class::PATTERN create_version( Regexp.last_match[:v], interesting_entries: [#{response.effective_url}, Match: #{Regexp.last_match}] ) end逻辑要点404 即放弃changelog.md不存在或站点禁止访问时返回 nil探测无结果整体匹配 命名捕获组对响应正文执行PATTERN命中后从Regexp.last_match[:v]提取版本号逐行扫描天然取首个命中Ruby 的~返回第一个匹配位置而 changelog 最新版本置顶的惯例保证了首个命中即最高版本。本例中正则\#\# \[(?v\d\.[\.\d])\]在正文第 3 行命中## [1.0.8]故v 1.0.8记录取证信息interesting_entries携带哪个 URL、匹配到什么文本供输出阶段展示。该类的设计注释body_pattern.rb说明BodyPattern 专门用于响应非 HTML 文档、无法走 XPath 解析的场景。Markdown/纯文本 changelog 正是典型用例——对比之下WpItemVersion::Comment、WpItemVersion::Xpath等分支则面向 HTML 响应如//comment()默认 XPath 见 comment.rb。3. 版本对象的封装命中后由 version/finder.rb 的create_version构造Model::Version并注入found_by: Change Log (Aggressive Detection)与默认置信度CONFIDENCE。这就是最终进入扫描结果、并与漏洞数据库lib/wpscan/db/vuln_api.rb比对的基础版本对象。四、模式库速览ChangeLog 在 dynamic_finders.yml 中的多种形态sticky-header-oceanwp并非孤例。在 spec/fixtures/db/dynamic_finders.yml 中ChangeLog 探测存在多种命名与正则形态理解这些差异有助于在真实站点扫描结果中判断版本来源的可信度# 形态一TXT changelog x.y.z 风格2fas 2fas: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^ (?v\d\.[\.\d])/i version: true # 形态二TXT changelogv 前缀版本300form 300form: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^v(?v\d\.[\.\da-z])(?!.*v\d\.[\.\da-z])/mi version: true # 形态三Markdown changelog## [x.y.z] 风格sticky-header-oceanwp本文实例 sticky-header-oceanwp: ChangeLog: class: BodyPattern path: changelog.md pattern: !ruby/regexp /\#\# \[(?v\d\.[\.\d])\]/ version: true可归纳出三条规律路径不固定changelog.txt、CHANGELOG.txt、CHANGELOG.md、changelog.md均出现过完全取决于插件作者的文件命名习惯因此规则必须逐插件单独配置正则锚定格式前缀、v、## [用于定位版本行命名捕获组(?v...)是 WPScan 约定俗成的版本提取接口class: BodyPattern是 changelog 类探测的通用实现无论 TXT 还是 Markdown最终都走同一套 BodyPattern 匹配管线。五、如何在真实环境中观察与验证该机制1. 查看规则库更新 WPScan 数据库后本地规则文件即为生产环境的dynamic_finders.ymlwpscan --update # 之后可在 ~/.wpscan/db/dynamic_finders.yml 中检索 # grep -A4 sticky-header-oceanwp ~/.wpscan/db/dynamic_finders.yml仓库内对应的可读副本是 spec/fixtures/db/dynamic_finders.yml测试夹具 spec/fixtures/dynamic_finders/expected.yml 则记录了该规则的期望探测结果。2. 对目标站点发起插件枚举在真实 WordPress 站点上或本地搭建的测试环境可参考 spec/integration/setup_wp_test_env.shwpscan --url https://example.com --enumerate p --plugins-detection aggressive当目标站点安装了sticky-header-oceanwp且changelog.md可访问时WPScan 会请求/wp-content/plugins/sticky-header-oceanwp/changelog.md命中## [1.0.8]后报告该插件版本并标注found_by: Change Log (Aggressive Detection)。若插件作者更新了 changelog 置顶版本如新增## [1.0.9]探测结果将随之变化——这也是该机制对版本状态敏感性的体现。3. 用测试套件回归验证若需验证规则与匹配逻辑的改动可运行相关单元测试如 spec/lib/finders/dynamic_finder/version/body_pattern_spec.rb其中覆盖了PATH、PATTERN、CONFIDENCE常量注入与匹配行为。整套 fixture 测试通过wpscan --test或bundle exec rspec spec/执行。六、扩展与注意事项如何为插件贡献 ChangeLog 规则从本文实例出发若你希望让 WPScan 识别某个尚未覆盖的插件 changelog例如你的插件在 WordPress 仓库发布可在dynamic_finders.yml中按以下范式新增规则仅演示规则结构实际贡献请遵循 WPScan 官方动态 finder 提交流程your-plugin-slug: ChangeLog: class: BodyPattern path: changelog.txt # 或 CHANGELOG.md取决于插件实际文件 pattern: !ruby/regexp /你的版本行正则必须含 (?v...) 捕获组/ version: true设计正则时的注意事项锚定要精确优先匹配版本行的行首前缀如、## [、v避免误匹配正文中的其他数字捕获组命名必须为vBodyPattern#find通过Regexp.last_match[:v]取值这是硬性约定注意[Unreleased]之类的占位段如本文实例中## [Unreleased]不满足\d\.[\.\d]的数字要求会被正则自然跳过无需额外处理重复版本号场景正则取首个匹配若 changelog 未遵循最新置顶惯例可能得到非最新版本此时需在规则层面结合插件实际格式权衡如 300form 的负向前瞻(?!.*v\d...)即是为取最后一个版本而设计的变体。从配置装载plugin.rb、动态类生成finder.rb到 Aggressive 请求与 BodyPattern 匹配body_pattern.rb、版本对象封装version/finder.rbsticky-header-oceanwp的 changelog 探测完整贯穿了 WPScan 动态版本识别体系中最有代表性的一条链路——理解它也就理解了 WPScan 如何在不读取插件主文件的前提下仅凭一个随版本维护的 Markdown 文件完成精确的版本指纹提取。赞分享网络安全漏洞扫描渗透测试应用安全CLI【免费下载链接】wpscanWPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contactwpscan.com项目地址https://gitcode.com/gh_mirrors/wp/wpscan点击查看免费下载相关推荐WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制 导读 本文围绕 WPScan网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本动态检测实战解析以 elementor-templater CHANGELOG 为例WPScan 插件版本动态检测实战解析以 elementor templater CHANGELOG 为例 导读 本文以 WPScan 仓库中的测试夹具 el网络安全漏洞扫描渗透测试应用安全CLIWPScan 的 ChangeLog 动态查找器以 talkjs 插件 CHANGELOG.md 为例解析版本识别机制WPScan 的 ChangeLog 动态查找器以 talkjs 插件 CHANGELOG.md 为例解析版本识别机制 WPScan 在枚举 WordPres网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WPScan 动态版本识别之 ChangeLog 探测：以 sticky-header-oceanwp 插件为实例的源码级解析
网络安全漏洞扫描渗透测试应用安全CLI【免费下载链接】wpscanWPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contactwpscan.com项目地址https://gitcode.com/gh_mirrors/wp/wpscan点击查看免费下载WPScan 是一款面向安全专业人员与 WordPress 站点维护者的 WordPress 安全扫描器。插件、主题的精确版本识别是后续漏洞匹配的基础而ChangeLog变更日志探测正是 WPScan Dynamic Finders 体系中一条成熟、高频的版本取证路径。本文以仓库中的真实样例 spec/fixtures/dynamic_finders/plugin_version/sticky-header-oceanwp/change_log/changelog.md 为具体实例完整还原 WPScan 如何从插件目录中一个 Markdown 格式的 changelog 文件出发通过配置文件、动态类生成、BodyPattern 匹配到最终版本号输出的完整链路并给出可复用的模式扩展方法。一、实例全景一条 ChangeLog 探测链路的完整数据流在开始阅读源码之前先围绕本文核心实例——sticky-header-oceanwp 插件的变更日志把 WPScan 中与它相关的三份关键数据串起来就能立刻看到整个机制的全貌。1. 源文件插件作者提供的变更日志spec/fixtures/dynamic_finders/plugin_version/sticky-header-oceanwp/change_log/changelog.md 是 WordPress 官方插件仓库中sticky-header-oceanwp插件作者随版本维护的 changelog 文件WPScan 将其作为测试 fixture 收录用于验证探测逻辑# Changelog ## [1.0.8] - 2021-10-22 ## Bug fix - Fixed bug support all oceanwp demo templates as well ## [1.0.7] - 2021-10-22 ### Support WordPress 5.8 - Supporting until the latest version of WordPress 5.8 - Fixed z-index issue, works with woocommerce quick previews as well. - Appreciate mdmosharofsk for helping solve the bug ## [1.0.6] - 2021-03-27 ### Support WordPress 5.7 - Supporting until latest version of WordPress 5.7 ### Changed - Changed the functions order on the main.js file - Fixed issue number #3 ## [1.0.5] - 2020-05-25 ### Origial version from wordpress repository - Oceanwp sticky header plugin publish / updated on wordpress plugins repository. ### Changed - Readme file fixed ### Added - Changelog file. - France translations (.mo/.po) files, Thanks to: momo-fr, Bruno Tritsch (btpub). ## [Unreleased] ## [1.0.5] - 2018-09-24这份文件有几个对探测机制至关重要的结构特征版本号以## [x.y.z]的 Markdown 二级标题形式出现且[与版本号之间没有空格这是本插件采用的固定格式文件以最高版本1.0.8开头、逐代向下排列符合最新版本置顶的常见 changelog 惯例存在重复版本号两个1.0.5与[Unreleased]占位段说明changelog 并非严格结构化的机器可读文件必须依赖精心设计的正则与取首个匹配策略才能得到可靠结果。2. 数据库配置WPScan 如何知道去哪里找、怎么找WPScan 将插件版本探测规则集中维护在数据库文件 spec/fixtures/db/dynamic_finders.yml 中生产运行时由wpscan --update从官方 DB 拉取同名规则lib/wpscan/db/dynamic_finders/base.rb 指向DB_DIR/dynamic_finders.yml。sticky-header-oceanwp的配置如下sticky-header-oceanwp: ChangeLog: class: BodyPattern path: changelog.md pattern: !ruby/regexp /\#\# \[(?v\d\.[\.\d])\]/ version: true逐字段解读字段取值含义ChangeLog探测器名称逻辑意义上的变更日志探测但真正的实现类由class决定classBodyPattern将实例化WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern类详见 lib/wpscan/finders/dynamic_finder/wp_item_version.rbpathchangelog.md攻击面探测路径http://目标/wp-content/plugins/sticky-header-oceanwp/changelog.mdpattern/\#\# \[(?v\d\.[\.\d])\]/正则命名捕获组v提取版本号\#\# \[精确锚定 Markdown 二级标题的## [前缀versiontrue标记这是一个版本探测型 finder而非文件名枚举型3. 期望结果测试断言锁定的探测结论spec/fixtures/dynamic_finders/expected.yml 中登记了该样例的期望输出等价于一条可自动回归验证的事实记录sticky-header-oceanwp: ChangeLog: number: 1.0.8 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/sticky-header-oceanwp/changelog.md, Match: ## [1.0.8]关键信息number: 1.0.8最终认定的插件版本是 changelog 中最新置顶的一个版本found_by: Change Log (Aggressive Detection)判定方式为 Aggressive主动请求指定路径而非 Passive仅分析首页/404 页响应interesting_entries记录命中的精确 URL 与匹配文本## [1.0.8]这是后续向用户展示版本由何而来的依据。注意测试环境中的http://wp.lab是 WPScan 测试套件使用的虚拟目标主机名见 spec/spec_helper.rb生产环境下会替换为真实被扫描站点的 URL。二、规则装载从 YAML 配置到动态 finder 类实例化配置数据本身不会自动变成可执行的探测代码WPScan 在扫描启动阶段完成配置 → 类的转换这一过程由 lib/wpscan/db/dynamic_finders/plugin.rb 承担。1. 配置读取与聚合Plugin Base通过df_data方法从dynamic_finders.yml中取出plugins顶层节点plugin.rb再由versions_finders_configs过滤出所有带version: true的条目plugin.rb。sticky-header-oceanwp的ChangeLog条目正是因为带有version: true才会进入版本探测候选集。2. 按 slug 动态建模块maybe_create_module把插件 slug 分类化为 Ruby 常量名并创建对应模块plugin.rbsticky-header-oceanwp→WPScan::Finders::PluginVersion::StickyHeaderOceanwp。随后create_versions_finders遍历该 slug 的版本探测配置为每个 finder 创建子类若模块中已存在同名常量如已被人手编写过 finder直接复用否则调用version_finder_super_class(klass).create_child_class(mod, finder_class.to_sym, config)动态生成plugin.rb。这里的klass即配置中的class: BodyPattern因此超类是WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern。3. 子类常量的注入机制动态生成的核心在 lib/wpscan/finders/dynamic_finder/finder.rb 的create_child_class它把配置中的path、pattern、confidence等键值对写入新建类的PATH、PATTERN、CONFIDENCE常量。对本实例而言生成后的类等价于class StickyHeaderOceanwp::ChangeLog PATH changelog.md PATTERN /\#\# \[(?v\d\.[\.\d])\]/ CONFIDENCE 60 # BodyPattern 默认置信度 end其中CONFIDENCE并非来自 YAML而是 body_pattern.rb 中定义的默认值 60配置未显式覆盖时即采用该值。三、探测执行Aggressive 模式下 BodyPattern 的匹配逻辑1. 主动探测的调度入口WpItemVersion::BodyPattern继承自通用动态 finder 基类finder.rb其aggressive方法在PATH存在时执行def aggressive(opts {}) return unless self.class::PATH find(Browser.get(target.url(self.class::PATH)), opts) end即PATH changelog.md存在因此走 aggressive 分支用浏览器组件请求target.url(changelog.md)。目标插件目录 URL 由Target#url基于wp-content/plugins/sticky-header-oceanwp/拼接插件目录前缀定义在扫描器配置中参见 lib/wpscan/target.rb 的相关方法。2. BodyPattern 的匹配与版本对象创建响应返回后进入 body_pattern.rb 的核心匹配def find(response, _opts {}) return unless response.code ! 404 response.body ~ self.class::PATTERN create_version( Regexp.last_match[:v], interesting_entries: [#{response.effective_url}, Match: #{Regexp.last_match}] ) end逻辑要点404 即放弃changelog.md不存在或站点禁止访问时返回 nil探测无结果整体匹配 命名捕获组对响应正文执行PATTERN命中后从Regexp.last_match[:v]提取版本号逐行扫描天然取首个命中Ruby 的~返回第一个匹配位置而 changelog 最新版本置顶的惯例保证了首个命中即最高版本。本例中正则\#\# \[(?v\d\.[\.\d])\]在正文第 3 行命中## [1.0.8]故v 1.0.8记录取证信息interesting_entries携带哪个 URL、匹配到什么文本供输出阶段展示。该类的设计注释body_pattern.rb说明BodyPattern 专门用于响应非 HTML 文档、无法走 XPath 解析的场景。Markdown/纯文本 changelog 正是典型用例——对比之下WpItemVersion::Comment、WpItemVersion::Xpath等分支则面向 HTML 响应如//comment()默认 XPath 见 comment.rb。3. 版本对象的封装命中后由 version/finder.rb 的create_version构造Model::Version并注入found_by: Change Log (Aggressive Detection)与默认置信度CONFIDENCE。这就是最终进入扫描结果、并与漏洞数据库lib/wpscan/db/vuln_api.rb比对的基础版本对象。四、模式库速览ChangeLog 在 dynamic_finders.yml 中的多种形态sticky-header-oceanwp并非孤例。在 spec/fixtures/db/dynamic_finders.yml 中ChangeLog 探测存在多种命名与正则形态理解这些差异有助于在真实站点扫描结果中判断版本来源的可信度# 形态一TXT changelog x.y.z 风格2fas 2fas: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^ (?v\d\.[\.\d])/i version: true # 形态二TXT changelogv 前缀版本300form 300form: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^v(?v\d\.[\.\da-z])(?!.*v\d\.[\.\da-z])/mi version: true # 形态三Markdown changelog## [x.y.z] 风格sticky-header-oceanwp本文实例 sticky-header-oceanwp: ChangeLog: class: BodyPattern path: changelog.md pattern: !ruby/regexp /\#\# \[(?v\d\.[\.\d])\]/ version: true可归纳出三条规律路径不固定changelog.txt、CHANGELOG.txt、CHANGELOG.md、changelog.md均出现过完全取决于插件作者的文件命名习惯因此规则必须逐插件单独配置正则锚定格式前缀、v、## [用于定位版本行命名捕获组(?v...)是 WPScan 约定俗成的版本提取接口class: BodyPattern是 changelog 类探测的通用实现无论 TXT 还是 Markdown最终都走同一套 BodyPattern 匹配管线。五、如何在真实环境中观察与验证该机制1. 查看规则库更新 WPScan 数据库后本地规则文件即为生产环境的dynamic_finders.ymlwpscan --update # 之后可在 ~/.wpscan/db/dynamic_finders.yml 中检索 # grep -A4 sticky-header-oceanwp ~/.wpscan/db/dynamic_finders.yml仓库内对应的可读副本是 spec/fixtures/db/dynamic_finders.yml测试夹具 spec/fixtures/dynamic_finders/expected.yml 则记录了该规则的期望探测结果。2. 对目标站点发起插件枚举在真实 WordPress 站点上或本地搭建的测试环境可参考 spec/integration/setup_wp_test_env.shwpscan --url https://example.com --enumerate p --plugins-detection aggressive当目标站点安装了sticky-header-oceanwp且changelog.md可访问时WPScan 会请求/wp-content/plugins/sticky-header-oceanwp/changelog.md命中## [1.0.8]后报告该插件版本并标注found_by: Change Log (Aggressive Detection)。若插件作者更新了 changelog 置顶版本如新增## [1.0.9]探测结果将随之变化——这也是该机制对版本状态敏感性的体现。3. 用测试套件回归验证若需验证规则与匹配逻辑的改动可运行相关单元测试如 spec/lib/finders/dynamic_finder/version/body_pattern_spec.rb其中覆盖了PATH、PATTERN、CONFIDENCE常量注入与匹配行为。整套 fixture 测试通过wpscan --test或bundle exec rspec spec/执行。六、扩展与注意事项如何为插件贡献 ChangeLog 规则从本文实例出发若你希望让 WPScan 识别某个尚未覆盖的插件 changelog例如你的插件在 WordPress 仓库发布可在dynamic_finders.yml中按以下范式新增规则仅演示规则结构实际贡献请遵循 WPScan 官方动态 finder 提交流程your-plugin-slug: ChangeLog: class: BodyPattern path: changelog.txt # 或 CHANGELOG.md取决于插件实际文件 pattern: !ruby/regexp /你的版本行正则必须含 (?v...) 捕获组/ version: true设计正则时的注意事项锚定要精确优先匹配版本行的行首前缀如、## [、v避免误匹配正文中的其他数字捕获组命名必须为vBodyPattern#find通过Regexp.last_match[:v]取值这是硬性约定注意[Unreleased]之类的占位段如本文实例中## [Unreleased]不满足\d\.[\.\d]的数字要求会被正则自然跳过无需额外处理重复版本号场景正则取首个匹配若 changelog 未遵循最新置顶惯例可能得到非最新版本此时需在规则层面结合插件实际格式权衡如 300form 的负向前瞻(?!.*v\d...)即是为取最后一个版本而设计的变体。从配置装载plugin.rb、动态类生成finder.rb到 Aggressive 请求与 BodyPattern 匹配body_pattern.rb、版本对象封装version/finder.rbsticky-header-oceanwp的 changelog 探测完整贯穿了 WPScan 动态版本识别体系中最有代表性的一条链路——理解它也就理解了 WPScan 如何在不读取插件主文件的前提下仅凭一个随版本维护的 Markdown 文件完成精确的版本指纹提取。赞分享网络安全漏洞扫描渗透测试应用安全CLI【免费下载链接】wpscanWPScan WordPress security scanner. Written for security professionals and blog maintainers to test the security of their WordPress websites. Contact us via contactwpscan.com项目地址https://gitcode.com/gh_mirrors/wp/wpscan点击查看免费下载相关推荐WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制 导读 本文围绕 WPScan网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本动态检测实战解析以 elementor-templater CHANGELOG 为例WPScan 插件版本动态检测实战解析以 elementor templater CHANGELOG 为例 导读 本文以 WPScan 仓库中的测试夹具 el网络安全漏洞扫描渗透测试应用安全CLIWPScan 的 ChangeLog 动态查找器以 talkjs 插件 CHANGELOG.md 为例解析版本识别机制WPScan 的 ChangeLog 动态查找器以 talkjs 插件 CHANGELOG.md 为例解析版本识别机制 WPScan 在枚举 WordPres网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考