网络安全漏洞扫描渗透测试应用安全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点击查看免费下载导读WordPress 插件常常会随安装包附带一份CHANGELOG.md或changelog.txt其中按版本号记录了变更历史。WPScan 充分利用了这一事实在枚举插件版本时扫描器会主动请求这类变更日志文件并从其中的版本号行快速识别出插件当前版本。本文以仓库中 bonaire 插件版本检测的测试夹具fixtureCHANGELOG.md 为切入点结合expected.yml预期结果与dynamic_finders.yml配置、以及BodyPattern与 Readme 解析器的源码实现完整讲解 WPScan 的 ChangeLog 动态查找器Dynamic Finder的工作原理、配置写法与检测置信度帮助你理解扫描输出的版本号究竟从何而来。bonaire 插件的 CHANGELOG.md一份典型的版本检测目标仓库中spec/fixtures/dynamic_finders/plugin_version/bonaire/change_log/CHANGELOG.md是用于验证 WPScan 动态查找器行为的测试夹具完整内容如下# Change Log All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). ## Version 0.1.1 ### Changed - Code cleanup - Ensured compatibility with PHPMailer ## Version 0.1.0 First commit.这份文件本身是虚构插件bonaire的变更日志它遵循Keep a Changelog与Semantic Versioning语义化版本两个社区规范每个版本用## Version x.y.z标题隔开标题行中明确包含版本号。正是这种标题行携带版本号的固定格式让 WPScan 可以在拿到该文件后用一行正则即可稳定提取最新版本。与这份夹具对应的预期检测结果记录在 spec/fixtures/dynamic_finders/expected.yml 中bonaire: ChangeLog: number: 0.1.1 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/bonaire/CHANGELOG.md, Match: Version 0.1.1该条目传达了三层关键信息检测类型为ChangeLogWPScan 将从插件自带的变更日志文件提取版本视为一种独立的动态查找器类型命中版本号为0.1.1即文件中以## Version 0.1.1标题出现、且按语义化版本排序后的最高版本命中方式为found_by: Change Log (Aggressive Detection)说明该检测属于主动Aggressive探测——扫描器会主动请求wp-content/plugins/bonaire/CHANGELOG.md这个 URL并在响应正文中匹配到Version 0.1.1字样。动态查找器机制ChangeLog 是允许的查找器类型之一ChangeLog并不是一个硬编码在扫描流程里的独立类而是通过 WPScan 的**动态查找器Dynamic Finder**体系驱动的。其核心配置定义在 lib/wpscan/db/dynamic_finders/base.rb 中# return [ ArraySymbol ] 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从源码注释可以明确看到Readme被刻意排除在动态查找器之外因为readme.txt的解析是独立机制见下文而BodyPattern等类才是真正的动态查找器。ChangeLog检测正是通过配置为class: BodyPattern的条目来实现的——这一点可以在真实配置 spec/fixtures/db/dynamic_finders.yml 中看到典型写法以2fas插件为例2fas: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^ (?v\d\.[\.\d])/i version: true Readme: path: readme.txt TranslationFile: class: BodyPattern path: languages/2fas-pt_BR.po pattern: !ruby/regexp /ion: 2FAS [^\s] Two Factor Authentication (?v\d\.[\.\d])/i version: true这里展示了动态查找器配置的通用结构每一项字段含义如下字段含义示例值ChangeLog/TranslationFile等动态查找器名称用于定位配置ChangeLogclass实际使用的查找器实现类必须属于allowed_classesBodyPatternpath相对插件目录wp-content/plugins/slug/的检测文件路径changelog.txt、CHANGELOG.md、languages/2fas-pt_BR.popattern提取版本号的正则必须包含(?v...)命名捕获组/^ (?v\d\.[\.\d])/iversion标记该查找器用于提取版本号而非用于确认插件存在true可以看出ChangeLog 类查找器的本质是在插件目录下某个已知路径的变更日志文件中用正则匹配版本号。只要path指向changelog.txt、CHANGELOG.md等约定文件名并给出适配该文件格式的pattern即可完成一次版本探测。配置的分发由 lib/wpscan/db/dynamic_finders/base.rb 中的method_missing完成当代码调用aggressive_xxx_finder_configs之类的接口时会根据allowed_classes校验类名再返回对应查找器配置。而expected.yml中 bonaire 条目的found_by: Change Log (Aggressive Detection)正是这种Aggressive ChangeLog组合在输出层呈现出来的形式。BodyPattern 底层实现一次请求 一次正则匹配ChangeLog 检测最终由BodyPattern类执行。其实现位于 lib/wpscan/finders/dynamic_finder/version/body_pattern.rbclass BodyPattern Finders::DynamicFinder::Version::Finder # return [ Hash ] def self.child_class_constants child_class_constants || super.merge(PATTERN: nil, CONFIDENCE: 60) end # param [ Typhoeus::Response ] response # param [ Hash ] opts # return [ Version ] 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其工作流程可以拆解为四步发起请求aggressive模式会根据配置中的PATH拼出完整 URL 并发起请求调用链见 lib/wpscan/finders/dynamic_finder/finder.rbdef aggressive(opts {}) return unless self.class::PATH find(Browser.get(target.url(self.class::PATH)), opts) end排除 404只有响应状态码不是 404 时才继续匹配避免把文件不存在误判为版本信息。正则提取将响应正文与配置中的PATTERN进行匹配并通过命名捕获组(?v...)取出版本号。生成 Version 模型调用 lib/wpscan/finders/dynamic_finder/version/finder.rb 的create_version把正则匹配片段写入interesting_entries——这与expected.yml中Match: Version 0.1.1的格式完全吻合同时BodyPattern类默认置信度为60CONFIDENCE: 60。每个插件的查找器子类都由create_child_class见 lib/wpscan/finders/dynamic_finder/finder.rb在运行时按dynamic_finders.yml中的配置动态生成因此2fas的changelog.txt与 bonaire 的CHANGELOG.md虽然在文件路径与格式上不同却可以复用同一套BodyPattern逻辑。Readme 解析中的 ChangeLog Section另一种版本来源除了直接请求插件的CHANGELOG.mdWPScan 还会在解析插件标准的readme.txt时把其中的 **Changelog 章节ChangeLog Section**作为第二重版本来源。相关实现位于 app/finders/plugin_version/readme.rb# return [ String, nil ] The best version number detected from the changelog section def from_changelog_section(body) extracted_versions body.scan(/^\s(?:v(?:ersion)?\s*)?([0-9.-])[^]*$/i) return if extracted_versions.nil? || extracted_versions.empty? extracted_versions.flatten! # must contain at least one number extracted_versions extracted_versions.grep(/[0-9]/) sorted extracted_versions.sort do |x, y| Gem::Version.new(x) Gem::Version.new(y) rescue StandardError 0 end sorted.last end这段逻辑与 bonaire 的CHANGELOG.md场景高度呼应它扫描 版本号 形式的章节标题行兼容v/version前缀过滤掉不含数字的行再借助 Ruby 的Gem::Version对提取出的版本号做语义化排序取排序后的最后一个即最高版本作为检测结果。在 app/finders/plugin_version/readme.rb 的version_numbers方法中两个来源会被合并返回并携带不同的置信度来源found_by 消息置信度Stable TagReadme - Stable Tag (Aggressive Detection)80ChangeLog SectionReadme - ChangeLog Section (Aggressive Detection)50置信度差异体现了工程上的审慎Stable Tag是插件作者在 readme 头部声明的正式版本号可信度更高而从 Changelog 章节推断出的版本虽然实用但由于历史版本章节可能残留、格式不规范等原因可信度相对较低。对应的测试位于 spec/app/finders/plugin_version/readme_spec.rb其中用一个哈希表覆盖了大量真实插件的变化日志格式变体如1.3、2.64、2.0.66.33、1.2.3、2.1.5、3.1、1.5.9、1.0.4、2.27等逐一断言from_changelog_section的提取结果——这也为ChangeLog 检测对格式差异有较强容忍度提供了测试层面的佐证。如何在真实扫描中验证要在真实环境复现上述检测行为只需对目标站点运行插件枚举主动模式WPScan 会依次请求目标wp-content/plugins/slug/下的readme.txt、CHANGELOG.md、changelog.txt等已知路径ruby wpscan.rb --url https://example.com --enumerate p --plugins-detection aggressive当检测命中时CLI 输出中会以[!]行列出插件版本其found_by字段即本文所述来源之一如Change Log (Aggressive Detection)或Readme - ChangeLog Section (Aggressive Detection)。需要说明的是前提是目标站点允许通过 HTTP 直接访问这些文件——若服务器屏蔽了CHANGELOG.md这类路径或返回 404BodyPattern#find会因response.code ! 404判断失败而返回nil该来源自然失效这与源码中的守卫条件一致。小结通过 bonaire 的 CHANGELOG.md 这份测试夹具可以梳理出 WPScan 插件版本检测的一条完整链路约定路径变更日志文件CHANGELOG.md/changelog.txt作为可被主动探测的公开文件是版本信息的天然泄露点动态配置dynamic_finders.yml中以ChangeLogBodyPatternpathpattern描述检测方式运行时通过create_child_class动态生成查找器底层匹配BodyPattern#find通过一次 HTTP 请求与一次正则匹配提取(?v...)命名组并记录interesting_entries与默认置信度 60双保险readme 解析器的from_changelog_section另行从 版本 章节提取版本两者互为补充最终汇总到Version模型供扫描结果输出。理解这条链路有助于安全研究者判断扫描报告中插件版本号的可信度来源也能帮助插件开发者认识到一份格式规范的 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 插件版本检测实战以 Clear Floats Button 的 CHANGELOG.md 动态查找器为例WPScan 插件版本检测实战以 Clear Floats Button 的 CHANGELOG.md 动态查找器为例 本文以 WPScan 仓库中 clea网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本检测实战以 get-the-image 的 changelog.md 为例解析 ChangeLog 动态查找机制WPScan 插件版本检测实战以 get the image 的 changelog.md 为例解析 ChangeLog 动态查找机制 导读 WordPres网络安全漏洞扫描渗透测试应用安全CLIWPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制 导读 本文围绕 WPScan网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
网络安全漏洞扫描渗透测试应用安全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点击查看免费下载导读WordPress 插件常常会随安装包附带一份CHANGELOG.md或changelog.txt其中按版本号记录了变更历史。WPScan 充分利用了这一事实在枚举插件版本时扫描器会主动请求这类变更日志文件并从其中的版本号行快速识别出插件当前版本。本文以仓库中 bonaire 插件版本检测的测试夹具fixtureCHANGELOG.md 为切入点结合expected.yml预期结果与dynamic_finders.yml配置、以及BodyPattern与 Readme 解析器的源码实现完整讲解 WPScan 的 ChangeLog 动态查找器Dynamic Finder的工作原理、配置写法与检测置信度帮助你理解扫描输出的版本号究竟从何而来。bonaire 插件的 CHANGELOG.md一份典型的版本检测目标仓库中spec/fixtures/dynamic_finders/plugin_version/bonaire/change_log/CHANGELOG.md是用于验证 WPScan 动态查找器行为的测试夹具完整内容如下# Change Log All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). ## Version 0.1.1 ### Changed - Code cleanup - Ensured compatibility with PHPMailer ## Version 0.1.0 First commit.这份文件本身是虚构插件bonaire的变更日志它遵循Keep a Changelog与Semantic Versioning语义化版本两个社区规范每个版本用## Version x.y.z标题隔开标题行中明确包含版本号。正是这种标题行携带版本号的固定格式让 WPScan 可以在拿到该文件后用一行正则即可稳定提取最新版本。与这份夹具对应的预期检测结果记录在 spec/fixtures/dynamic_finders/expected.yml 中bonaire: ChangeLog: number: 0.1.1 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/bonaire/CHANGELOG.md, Match: Version 0.1.1该条目传达了三层关键信息检测类型为ChangeLogWPScan 将从插件自带的变更日志文件提取版本视为一种独立的动态查找器类型命中版本号为0.1.1即文件中以## Version 0.1.1标题出现、且按语义化版本排序后的最高版本命中方式为found_by: Change Log (Aggressive Detection)说明该检测属于主动Aggressive探测——扫描器会主动请求wp-content/plugins/bonaire/CHANGELOG.md这个 URL并在响应正文中匹配到Version 0.1.1字样。动态查找器机制ChangeLog 是允许的查找器类型之一ChangeLog并不是一个硬编码在扫描流程里的独立类而是通过 WPScan 的**动态查找器Dynamic Finder**体系驱动的。其核心配置定义在 lib/wpscan/db/dynamic_finders/base.rb 中# return [ ArraySymbol ] 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从源码注释可以明确看到Readme被刻意排除在动态查找器之外因为readme.txt的解析是独立机制见下文而BodyPattern等类才是真正的动态查找器。ChangeLog检测正是通过配置为class: BodyPattern的条目来实现的——这一点可以在真实配置 spec/fixtures/db/dynamic_finders.yml 中看到典型写法以2fas插件为例2fas: ChangeLog: class: BodyPattern path: changelog.txt pattern: !ruby/regexp /^ (?v\d\.[\.\d])/i version: true Readme: path: readme.txt TranslationFile: class: BodyPattern path: languages/2fas-pt_BR.po pattern: !ruby/regexp /ion: 2FAS [^\s] Two Factor Authentication (?v\d\.[\.\d])/i version: true这里展示了动态查找器配置的通用结构每一项字段含义如下字段含义示例值ChangeLog/TranslationFile等动态查找器名称用于定位配置ChangeLogclass实际使用的查找器实现类必须属于allowed_classesBodyPatternpath相对插件目录wp-content/plugins/slug/的检测文件路径changelog.txt、CHANGELOG.md、languages/2fas-pt_BR.popattern提取版本号的正则必须包含(?v...)命名捕获组/^ (?v\d\.[\.\d])/iversion标记该查找器用于提取版本号而非用于确认插件存在true可以看出ChangeLog 类查找器的本质是在插件目录下某个已知路径的变更日志文件中用正则匹配版本号。只要path指向changelog.txt、CHANGELOG.md等约定文件名并给出适配该文件格式的pattern即可完成一次版本探测。配置的分发由 lib/wpscan/db/dynamic_finders/base.rb 中的method_missing完成当代码调用aggressive_xxx_finder_configs之类的接口时会根据allowed_classes校验类名再返回对应查找器配置。而expected.yml中 bonaire 条目的found_by: Change Log (Aggressive Detection)正是这种Aggressive ChangeLog组合在输出层呈现出来的形式。BodyPattern 底层实现一次请求 一次正则匹配ChangeLog 检测最终由BodyPattern类执行。其实现位于 lib/wpscan/finders/dynamic_finder/version/body_pattern.rbclass BodyPattern Finders::DynamicFinder::Version::Finder # return [ Hash ] def self.child_class_constants child_class_constants || super.merge(PATTERN: nil, CONFIDENCE: 60) end # param [ Typhoeus::Response ] response # param [ Hash ] opts # return [ Version ] 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其工作流程可以拆解为四步发起请求aggressive模式会根据配置中的PATH拼出完整 URL 并发起请求调用链见 lib/wpscan/finders/dynamic_finder/finder.rbdef aggressive(opts {}) return unless self.class::PATH find(Browser.get(target.url(self.class::PATH)), opts) end排除 404只有响应状态码不是 404 时才继续匹配避免把文件不存在误判为版本信息。正则提取将响应正文与配置中的PATTERN进行匹配并通过命名捕获组(?v...)取出版本号。生成 Version 模型调用 lib/wpscan/finders/dynamic_finder/version/finder.rb 的create_version把正则匹配片段写入interesting_entries——这与expected.yml中Match: Version 0.1.1的格式完全吻合同时BodyPattern类默认置信度为60CONFIDENCE: 60。每个插件的查找器子类都由create_child_class见 lib/wpscan/finders/dynamic_finder/finder.rb在运行时按dynamic_finders.yml中的配置动态生成因此2fas的changelog.txt与 bonaire 的CHANGELOG.md虽然在文件路径与格式上不同却可以复用同一套BodyPattern逻辑。Readme 解析中的 ChangeLog Section另一种版本来源除了直接请求插件的CHANGELOG.mdWPScan 还会在解析插件标准的readme.txt时把其中的 **Changelog 章节ChangeLog Section**作为第二重版本来源。相关实现位于 app/finders/plugin_version/readme.rb# return [ String, nil ] The best version number detected from the changelog section def from_changelog_section(body) extracted_versions body.scan(/^\s(?:v(?:ersion)?\s*)?([0-9.-])[^]*$/i) return if extracted_versions.nil? || extracted_versions.empty? extracted_versions.flatten! # must contain at least one number extracted_versions extracted_versions.grep(/[0-9]/) sorted extracted_versions.sort do |x, y| Gem::Version.new(x) Gem::Version.new(y) rescue StandardError 0 end sorted.last end这段逻辑与 bonaire 的CHANGELOG.md场景高度呼应它扫描 版本号 形式的章节标题行兼容v/version前缀过滤掉不含数字的行再借助 Ruby 的Gem::Version对提取出的版本号做语义化排序取排序后的最后一个即最高版本作为检测结果。在 app/finders/plugin_version/readme.rb 的version_numbers方法中两个来源会被合并返回并携带不同的置信度来源found_by 消息置信度Stable TagReadme - Stable Tag (Aggressive Detection)80ChangeLog SectionReadme - ChangeLog Section (Aggressive Detection)50置信度差异体现了工程上的审慎Stable Tag是插件作者在 readme 头部声明的正式版本号可信度更高而从 Changelog 章节推断出的版本虽然实用但由于历史版本章节可能残留、格式不规范等原因可信度相对较低。对应的测试位于 spec/app/finders/plugin_version/readme_spec.rb其中用一个哈希表覆盖了大量真实插件的变化日志格式变体如1.3、2.64、2.0.66.33、1.2.3、2.1.5、3.1、1.5.9、1.0.4、2.27等逐一断言from_changelog_section的提取结果——这也为ChangeLog 检测对格式差异有较强容忍度提供了测试层面的佐证。如何在真实扫描中验证要在真实环境复现上述检测行为只需对目标站点运行插件枚举主动模式WPScan 会依次请求目标wp-content/plugins/slug/下的readme.txt、CHANGELOG.md、changelog.txt等已知路径ruby wpscan.rb --url https://example.com --enumerate p --plugins-detection aggressive当检测命中时CLI 输出中会以[!]行列出插件版本其found_by字段即本文所述来源之一如Change Log (Aggressive Detection)或Readme - ChangeLog Section (Aggressive Detection)。需要说明的是前提是目标站点允许通过 HTTP 直接访问这些文件——若服务器屏蔽了CHANGELOG.md这类路径或返回 404BodyPattern#find会因response.code ! 404判断失败而返回nil该来源自然失效这与源码中的守卫条件一致。小结通过 bonaire 的 CHANGELOG.md 这份测试夹具可以梳理出 WPScan 插件版本检测的一条完整链路约定路径变更日志文件CHANGELOG.md/changelog.txt作为可被主动探测的公开文件是版本信息的天然泄露点动态配置dynamic_finders.yml中以ChangeLogBodyPatternpathpattern描述检测方式运行时通过create_child_class动态生成查找器底层匹配BodyPattern#find通过一次 HTTP 请求与一次正则匹配提取(?v...)命名组并记录interesting_entries与默认置信度 60双保险readme 解析器的from_changelog_section另行从 版本 章节提取版本两者互为补充最终汇总到Version模型供扫描结果输出。理解这条链路有助于安全研究者判断扫描报告中插件版本号的可信度来源也能帮助插件开发者认识到一份格式规范的 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 插件版本检测实战以 Clear Floats Button 的 CHANGELOG.md 动态查找器为例WPScan 插件版本检测实战以 Clear Floats Button 的 CHANGELOG.md 动态查找器为例 本文以 WPScan 仓库中 clea网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本检测实战以 get-the-image 的 changelog.md 为例解析 ChangeLog 动态查找机制WPScan 插件版本检测实战以 get the image 的 changelog.md 为例解析 ChangeLog 动态查找机制 导读 WordPres网络安全漏洞扫描渗透测试应用安全CLIWPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制WPScan 动态识别插件版本以 BlockMeister 的 changelog.md 为例解读 ChangeLog 探测机制 导读 本文围绕 WPScan网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
