网络安全漏洞扫描渗透测试应用安全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点击查看免费下载WPScanWordPress 安全扫描器通过一套名为 Dynamic Finders动态指纹的机制从插件/主题的各类公开文件中提取安装版本号。本文以仓库测试夹具spec/fixtures/dynamic_finders/plugin_version/addy-autocomplete-woocommerce/change_log/CHANGELOG.md为实例系统讲解「ChangeLog → BodyPattern」这条版本检测链路从指纹配置dynamic_finders.yml、激进/被动检测语义到BodyPattern底层源码实现与测试期望输出。读完本文你将掌握 WPScan 动态指纹的配置格式、运行原理以及如何为任意插件编写基于 CHANGELOG 的版本识别规则。一、动态指纹Dynamic Finders机制概述WPScan 的版本识别并不依赖人工维护的指纹列表而是通过数据库文件db/dynamic_finders.yml声明「每个插件/主题可以从哪些文件中、用何种方式提取版本号」扫描时再动态生成对应的 Finder 类执行检测。从 lib/wpscan/db/dynamic_finders/base.rb 的源码可以看到机制的核心骨架def self.all_df_data all_df_data || YAML.safe_load_file(df_file, permitted_classes: [Regexp]) end def self.allowed_classes # The Readme is not put in there as its not a Real DF, but rather using the DF system # to get the list of potential filenames for a given slug allowed_classes || %i[Comment Xpath HeaderPattern BodyPattern JavascriptVar QueryParameter ConfigParser] end关键信息有三点指纹配置集中在db/dynamic_finders.yml其中允许出现 Ruby 正则permitted_classes: [Regexp]这正是指纹规则里pattern字段能直接写正则的原因动态指纹只包含 7 类Comment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParserReadme 不是真正的动态指纹它只是借用动态指纹体系来获取某插件的候选文件名列表用于枚举 readme.txt/README.md 等。我们本文的主角 —— ChangeLog 指纹正是依托第 2 点中的BodyPattern类实现的。二、关联文档一份作为指纹数据的插件 CHANGELOG关联文档 spec/fixtures/dynamic_finders/plugin_version/addy-autocomplete-woocommerce/change_log/CHANGELOG.md 本身是一份真实的 WordPress 插件变更日志内容为「NZ Address Autocomplete for WooCommerce」新西兰地址自动补全插件由新西兰奥克兰的 Addy 团队开发从 2.0.0 到 2.1.2 的版本演进记录# NZ Address Autocomplete for WooCommerce 2.1.2 # * Call update events when an address is auto-completed # NZ Address Autocomplete for WooCommerce 2.1.1 # * Added additional filters and configuration options # NZ Address Autocomplete for WooCommerce 2.1.0.2 # * Use Mailtown instead of City by default ... # NZ Address Autocomplete for WooCommerce 2.0.0 # * Addy, proudly made out of Auckland, New Zealand在 WPScan 的仓库中这份文件并非孤立存在而是动态指纹体系的测试夹具fixture它模拟了真实 WordPress 站点上wp-content/plugins/addy-autocomplete-woocommerce/CHANGELOG.md的内容用于验证「通过 changelog 提取插件版本」这条检测路径。仓库spec/fixtures/dynamic_finders/plugin_version/目录下还有大量同类夹具如disable-search/change_log/CHANGELOG.md、remote-cache-purger/change_log/changelog.txt等说明ChangeLog 是 WPScan 覆盖最广的版本指纹类型之一。三、指纹配置ChangeLog 如何在dynamic_finders.yml中声明在 spec/fixtures/db/dynamic_finders.yml 的第 3522 行起可以看到针对该插件的完整指纹声明addy-autocomplete-woocommerce: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /(?v\d\.[\.\d])/ version: true逐字段解读这份配置字段值含义ChangeLog键名指纹名称同时也是输出found_by标签的来源classBodyPattern实际使用的检测器类ChangeLog 指纹统一复用 BodyPattern 实现pathCHANGELOG.md需要请求的插件内相对路径即wp-content/plugins/slug/CHANGELOG.mdpattern/(?v\d\.[\.\d])/命名捕获组正则v即版本号所在位置versiontrue标记这是一个「版本查找器」会被收集进版本指纹配置注意其中的正则/(?v\d\.[\.\d])/先匹配至少一位数字随后是点号再跟[\.\d]点或数字的任意组合。因此在 changelog 中遇到2.1.2时捕获组v会完整匹配到2.1.2而2.1.0.2这类四段式版本同样能被完整捕获。该正则的匹配语义与 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb 中Regexp.last_match[:v]的取值逻辑一一对应。激进Aggressive与被动Passive的判定配置中是否带path直接决定了该指纹属于哪一类检测。在 lib/wpscan/db/dynamic_finders/plugin.rb 的finder_configs中可以看到明确的切分逻辑fs if aggressive finders.reject { |_f, c| c[path].nil? } else finders.select { |_f, c| c[path].nil? } end带path的如 ChangeLog 指向CHANGELOG.md→ 激进检测Aggressive需要扫描器主动发起一次对具体文件的 HTTP 请求不带path的如 Comment、JavascriptVar 等→ 被动检测Passive直接从主页等已获取的响应内容中匹配。所以ChangeLog 指纹在输出中会被标记为Change Log (Aggressive Detection)这一点在 spec/fixtures/dynamic_finders/expected.yml第 1727–1733 行中有明确记录addy-autocomplete-woocommerce: ChangeLog: number: 2.1.2 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/addy-autocomplete-woocommerce/CHANGELOG.md, Match: 2.1.2这份 expected.yml 是该夹具对应的期望输出版本号2.1.2changelog 最顶部的版本、检测方式Change Log (Aggressive Detection)、以及命中详情请求的 URL 与正则匹配到的原文。测试运行时扫描器会在模拟站点http://wp.lab上请求该 changelog并断言结果与期望完全一致。四、底层实现BodyPattern 如何从 CHANGELOG 中提取版本配置只是声明真正干活的是运行时动态生成的 Finder 类。整个过程分两步第一步按配置动态生成检测类lib/wpscan/db/dynamic_finders/plugin.rb 的create_versions_finders会遍历versions_finders_configs即所有version: true的配置为每个插件 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其中maybe_create_module会把addy-autocomplete-woocommerce这样的 slug 规范化为AddyAutocompleteWoocommerce模块名见同文件中的classify_slug逻辑注释并挂载到Finders::PluginVersion命名空间下version_finder_super_class(klass)则将BodyPattern解析为WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern作为父类子类会继承配置中的PATTERN常量。第二步请求文件并执行正则匹配子类实例化后检测逻辑落在 lib/wpscan/finders/dynamic_finder/version/body_pattern.rbclass BodyPattern Finders::DynamicFinder::Version::Finder def self.child_class_constants child_class_constants || super.merge(PATTERN: nil, CONFIDENCE: 60) end 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 end核心逻辑只有三行但信息量很大404 短路若目标站点没有CHANGELOG.md返回 404直接返回空结果不会误报正则取版本response.body ~ PATTERN命中后通过命名捕获组v取出版本号Regexp.last_match[:v]留痕可审计interesting_entries记录「请求的完整 URL 正则匹配到的原文」这既是扫描报告的取证信息也直接对应 expected.yml 中的interesting_entries字段。此外CONFIDENCE: 60是 BodyPattern 类的默认置信度通过 lib/wpscan/finders/dynamic_finder/version/finder.rb 的version_finding_opts注入到最终结果中若配置未显式覆盖confidence字段则取该默认值。五、从配置到结果一次完整的版本识别流程综合上述源码addy-autocomplete-woocommerce的版本检测完整链路如下1. 加载 db/dynamic_finders.ymlYAML.safe_load_file允许 Regexp 类 2. 提取 addy-autocomplete-woocommerce 下 version: true 的指纹 └─ ChangeLog: classBodyPattern, pathCHANGELOG.md, pattern/(?v\d\.[\.\d])/ 3. 因配置含 path判定为 Aggressive激进检测 4. 动态创建 Finders::PluginVersion::AddyAutocompleteWoocommerce::ChangeLog 5. 请求 http://target/wp-content/plugins/addy-autocomplete-woocommerce/CHANGELOG.md 6. 响应非 404 且 body 匹配 pattern → 捕获 v 2.1.2 7. 生成 Version 对象number2.1.2, confidence60, found_byChange Log (Aggressive Detection), interesting_entries[URL Match: 2.1.2]其中第 6 步能匹配到2.1.2的原因在于Ruby 的~返回首次命中位置而 changelog 顶部第一行标题就是# NZ Address Autocomplete for WooCommerce 2.1.2 #正则从左到右扫描时最先命中的完整版本串即为2.1.2随后会被用于匹配更靠后的2.1.1、2.1.0等旧版本但首命中即返回。六、实战如何为一个新插件编写 CHANGELOG 版本指纹掌握了配置格式与底层实现后为任意插件新增 changelog 版本识别只需两步第一步准备指纹数据对应仓库中的夹具目录将插件官方发布的 CHANGELOG 文件按如下布局放入夹具目录仅供测试/演示生产环境的数据由 WPScan 数据库更新机制下发spec/fixtures/dynamic_finders/plugin_version/plugin-slug/change_log/CHANGELOG.md第二步在dynamic_finders.yml中登记规则plugin-slug: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /(?v\d\.[\.\d])/ version: true编写时需要注意的实践要点路径大小写路径必须与插件实际文件名完全一致CHANGELOG.mdvschangelog.txt是不同的文件仓库夹具中两种命名都有收录如remote-cache-purger/change_log/changelog.txt使用小写.txt正则的捕获组名必须是vBodyPattern 的实现固定读取Regexp.last_match[:v]其他组名不会被识别保证版本串的完整性若插件 changelog 中混有其他数字如年份需收紧正则避免误捕\d\.[\.\d]这类宽松写法适用于大多数纯版本号的场景匹配结果服从「首命中」规则文件顶部应是最新版本否则提取到的可能是旧版本号found_by标签自动生成无需手工配置WPScan 会依据指纹名ChangeLog与激进/被动属性输出Change Log (Aggressive Detection)之类的标签。七、机制的边界与设计取舍从源码结构可以推断出该机制的几项设计取舍Readme 被刻意排除在动态指纹之外见 lib/wpscan/db/dynamic_finders/base.rb 注释因为 readme 主要用于枚举候选文件名其版本格式不规范、命中不可靠所以不按「真实指纹」对待新增指纹类需要同步扩展allowed_classesBodyPattern 之所以能承载 ChangeLog 指纹是因为它位于允许列表内若未来需要全新的检测方式如解析二进制文件头必须先在allowed_classes中注册否则method_missing与create_versions_finders都会直接跳过配置与代码解耦指纹规则全部来自 YAML 数据文件扫描器代码无需随每条新指纹发布用户更新 WPScan 数据库wpscan --update即可获得新插件的识别能力这正是动态指纹体系的核心价值。理解这条链路后你在阅读 WPScan 扫描报告时就能从found_by: Change Log (Aggressive Detection)这类标签反推出底层行为扫描器主动请求了插件的CHANGELOG.md用正则提取了顶部版本号并以 60 的置信度将该结果纳入版本判定 —— 而这正是addy-autocomplete-woocommerce这份 changelog 夹具在仓库中存在的意义。赞分享网络安全漏洞扫描渗透测试应用安全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 插件版本检测实战以 ACF Options for Polylang 的 CHANGELOG.md 为指纹案例WPScan 插件版本检测实战以 ACF Options for Polylang 的 CHANGELOG.md 为指纹案例 WPScan 作为 WordPr网络安全漏洞扫描渗透测试应用安全CLI深度解析 WPScan 动态版本识别以 404-solution 插件 CHANGELOG.md 指纹为例深度解析 WPScan 动态版本识别以 404 solution 插件 CHANGELOG.md 指纹为例 WPScan 作为 WordPress 安全扫描器网络安全漏洞扫描渗透测试应用安全CLI从 CHANGELOG.md 指纹到版本号WPScan 插件版本动态发现机制ChangeLog Detection深度解析从 CHANGELOG.md 指纹到版本号WPScan 插件版本动态发现机制ChangeLog Detection深度解析 导读 WordPress 插件网络安全漏洞扫描渗透测试应用安全CLI上一篇【亲测免费】 探索创新SpeechGPT - 语音识别与合成的新里程碑下一篇Tooll3 v3.6 功能纵览色彩与渐变工作流、Dope-Sheet 自动固定、符号浏览器智能排序与新增渲染算子创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
