网络安全漏洞扫描渗透测试应用安全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 安全扫描器其核心能力之一是动态指纹Dynamic Finders不依赖集中式版本数据库而是直接请求目标站点上的真实文件如CHANGELOG.md、readme.txt用正则从文件内容中提取插件或主题版本号。本文以仓库 fixture 中 download-monitor-learndash-integration/change_log/CHANGELOG.md 为样本完整讲解「CHANGELOG 版本指纹」从配置、正则设计、请求策略到源码落地的全过程读完即可自己为任意插件编写同类指纹。一、样本指纹与配套配置一份真实的 CHANGELOG 指纹先看这个插件的真实变更日志样本fixture 文件全文spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/change_log/CHANGELOG.md### 1.0.1: 23.09.2022 * Fixed: Checking group administrators ( [#1](https://github.com/WPChill/download-monitor-learndash-integration/issues/1) ) ### 1.0.0: TBA * Initial Release该插件 slug 为download-monitor-learndash-integration其在 WPScan 数据库中的指纹配置位于 spec/fixtures/db/dynamic_finders.ymldownload-monitor-learndash-integration: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?v\d\.[\.\d])/ version: true Readme: path: readme.txt逐字段拆解字段值含义ChangeLog—该 finder 的名称key同时会作为动态生成的子类常量名classBodyPattern指定使用的动态查找器实现类本指纹属于「响应正文正则匹配」类型pathCHANGELOG.md需要请求的插件内相对路径启用 aggressive激进模式时访问pattern/\#\# (?v\d\.[\.\d])/用于从正文中捕获版本号的正则v为命名捕获组versiontrue标记该配置是版本指纹区别于Readme那种只用于收集候选文件名的配置注意同 slug 下还配置了Readme: path: readme.txt它没有version: true。这正是 WPScan 的设计细节Readme 不是真正的动态指纹它只是借助动态指纹系统来获取一个插件可能的文件名列表lib/wpscan/db/dynamic_finders/base.rb 的注释明确说明“The Readme is not put in there as its not a Real DF”而真正用于版本识别的是version: true的ChangeLog配置。二、模式一被动Passive——不额外发请求动态 finder 分为被动与激进两种执行路径由 lib/wpscan/finders/dynamic_finder/finder.rb 的基类控制def passive(opts {}) return if self.class::PATH # 配置了 path 的 finder 不做被动检测 homepage_result find(target.homepage_res, opts) return homepage_result unless homepage_result.nil? || homepage_result.empty? find(target.error_404_res, opts) end def aggressive(opts {}) return unless self.class::PATH # 没有 path 的 finder 不做激进检测 find(Browser.get(target.url(self.class::PATH)), opts) end对本样本的ChangeLog指纹而言由于配置了path: CHANGELOG.md被动模式直接跳过return if self.class::PATH不会在首页或 404 页面里寻找版本号激进模式才会发起GET {target_url}/wp-content/plugins/download-monitor-learndash-integration/CHANGELOG.md请求把响应正文交给BodyPattern解析。而Readme配置因为没有class、pattern只承担文件名提示功能不参与版本正则匹配。这种「被动零额外请求、激进按需请求」的设计保证了扫描器在默认被动枚举时不会引入多余流量。三、模式二激进Aggressive——请求真实文件并匹配正则当启用插件枚举如--enumerate p或--plugins-detection aggressive时WPScan 会按配置的path发起请求然后由BodyPattern实现类解析响应。核心逻辑在 lib/wpscan/finders/dynamic_finder/version/body_pattern.rbdef 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 响应直接返回nil目标站未安装该插件或文件被改名/删除非 404 时用配置的pattern对正文做正则匹配命中后取命名捕获组v作为版本号并记录interesting_entries包含有效 URL 与完整匹配片段作为取证信息写入扫描报告版本对象由 lib/wpscan/finders/dynamic_finder/version/finder.rb 的create_version构造默认置信度取子类常量CONFIDENCEBodyPattern为 60见 body_pattern.rb。针对本样本正则/\#\# (?v\d\.[\.\d])/匹配正文中的## 1.0.1、## 1.0.0最终返回1.0.1第一个命中。四、正则设计为什么这样写以及它的局限样本正则\#\# (?v\d\.[\.\d])反映了 Markdown 变更日志的通用形态\#\#匹配 Markdown 二级标题##本样本用的是###三级标题但##是###的前缀子串所以仍能命中版本号文本(?v...)命名捕获组\d\.[\.\d]匹配1.0.1这类「数字开头、点分隔」的版本串1.0.0、1.0.1均可只取第一个##开头的匹配——通常最新版本写在最上方符合绝大多数插件的变更日志惯例。对照组同仓库中另一插件 download-monitor-paid-membership-pro-integration 的正则/^\# (?v\d\.[\.\d])(?!.*\# \d\.[\.\d])/mi使用了行首锚定^、\#兼容#/##/###以及负向前瞻(?!...)来排除“标题中同时出现多个版本号”的干扰见 spec/fixtures/db/dynamic_finders.yml说明编写指纹时需针对具体文件的标题层级做微调。样本正则的局限也很明显属于可以如实说明的已知边界若变更日志把版本号写在## 1.0.1 (2022-09-23)这种带括号日期、且日期含.的标题里\d\.[\.\d]可能把日期也吃进去本样本的### 1.0.1: 23.09.2022中日期前有冒号和空格正则在1.0.1后的空格处停止恰好不受影响依赖文件存在且未改名的前提若站点把CHANGELOG.md改名或删除激进指纹即失效——这也正是 WPScan 同时配置多种 finder如Readme、BodyPattern、QueryParameter等互为补充的原因。五、源码链路从 YAML 配置到动态子类从配置到实际执行的完整调用链如下加载配置lib/wpscan/db/dynamic_finders/base.rb 将dynamic_finders.yml以 YAML 形式加载为all_df_data允许Regexp类型Plugin.df_data取其中的plugins段过滤版本指纹lib/wpscan/db/dynamic_finders/plugin.rb 的versions_finders_configs只收集带version: true的配置next unless config.key?(version)本样本的ChangeLog因此入选Readme被排除生成子类create_versions_finders先通过maybe_create_module按 slug 生成模块如DownloadMonitorLearndashIntegration再由 lib/wpscan/finders/dynamic_finder/finder.rb 的create_child_class用Class.new(self)动态创建子类把 YAML 中的path、pattern等写入子类常量执行匹配基类aggressive请求CHANGELOG.mdBodyPattern#find用子类常量PATTERN匹配并返回版本。类白名单在 lib/wpscan/db/dynamic_finders/base.rbComment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParser非白名单类会被拒绝防止通过外部 YAML 注入任意类。六、配套测试与验证方式WPScan 为每种动态 finder 都配有 RSpec 测试位于 spec/lib/finders/dynamic_finder/version/其中 body_pattern_spec.rb 覆盖了BodyPattern的命中与未命中分支。fixture 目录 spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/ 正是为这类测试提供真实抓取样本change_log/CHANGELOG.md保存了目标插件真实变更日志测试通过 mock HTTP 响应来验证正则能否正确提取1.0.1。本地验证正则是否可用无需跑完整扫描直接用 Ruby 单行即可复现ruby -e body File.read(spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/change_log/CHANGELOG.md); if body ~ /\#\# (?v\d\.[\.\d])/ then puts Regexp.last_match[:v]; end预期输出1.0.1与配置声明的版本指纹一致。若输出与预期不符通常需要调整pattern的标题层级或版本号字符类。七、把该方法推广到其他插件的实操清单基于上述链路为任意 WordPress 插件新增 CHANGELOG 版本指纹的通用步骤抓取该插件站内真实CHANGELOG.md或readme.txt放入spec/fixtures/dynamic_finders/plugin_version/slug/change_log/作为样本在dynamic_finders.yml的plugins段为该 slug 增加ChangeLog配置字段为class: BodyPattern、path: CHANGELOG.md、pattern带(?v...)命名捕获组、version: true按样本实际标题格式调整正则三级标题用\#\#\#、兼容多级用^\#、存在日期后缀时用负向前瞻排除多版本行用ruby -e单行脚本对照 fixture 样本先本地验证再补充body_pattern_spec.rb风格的 RSpec 用例联调验证wpscan --url 目标站 --enumerate p --plugins-detection aggressive观察报告中的found_by: Body Pattern与置信度 60。八、小结Download Monitor Learndash Integration 的 CHANGELOG 指纹是理解 WPScan 动态指纹体系的最佳入门样本它同时展示了version: true真版本指纹与Readme文件名提示两种配置形态串起了「YAML 配置 → 动态子类生成 → 被动/激进请求分流 → BodyPattern 正则匹配」的完整链路也暴露了正则写法对变更日志格式的敏感性与演进方向。掌握这套方法后你既能读懂 WPScan 内置的数千条插件指纹也能为扫描器贡献高质量的版本识别规则。赞分享网络安全漏洞扫描渗透测试应用安全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 插件版本指纹实战以 OptinMonster CHANGELOG 指纹为例WPScan 插件版本指纹实战以 OptinMonster CHANGELOG 指纹为例 本文以 WPScan 仓库中一份真实测试样例——OptinMonst网络安全漏洞扫描渗透测试应用安全CLIWPScan 动态指纹机制实战解析以 addy-autocomplete-woocommerce 的 CHANGELOG 版本检测为例WPScan 动态指纹机制实战解析以 addy autocomplete woocommerce 的 CHANGELOG 版本检测为例 WPScanWord网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本指纹识别实战以 nerd-wp CHANGELOG.md 测试样本为例解读 Change Log 动态指纹器WPScan 插件版本指纹识别实战以 nerd wp CHANGELOG.md 测试样本为例解读 Change Log 动态指纹器 本文以 WPScan网络安全漏洞扫描渗透测试应用安全CLI上一篇3分钟免费解锁Wand完整功能游戏修改器终极解决方案下一篇JuiceFS 如何用 fio 跑顺序读写基准测试并解读结果创作声明：本文部分内容由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点击查看免费下载WPScan 是面向安全专业人员和博客维护者的 WordPress 安全扫描器其核心能力之一是动态指纹Dynamic Finders不依赖集中式版本数据库而是直接请求目标站点上的真实文件如CHANGELOG.md、readme.txt用正则从文件内容中提取插件或主题版本号。本文以仓库 fixture 中 download-monitor-learndash-integration/change_log/CHANGELOG.md 为样本完整讲解「CHANGELOG 版本指纹」从配置、正则设计、请求策略到源码落地的全过程读完即可自己为任意插件编写同类指纹。一、样本指纹与配套配置一份真实的 CHANGELOG 指纹先看这个插件的真实变更日志样本fixture 文件全文spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/change_log/CHANGELOG.md### 1.0.1: 23.09.2022 * Fixed: Checking group administrators ( [#1](https://github.com/WPChill/download-monitor-learndash-integration/issues/1) ) ### 1.0.0: TBA * Initial Release该插件 slug 为download-monitor-learndash-integration其在 WPScan 数据库中的指纹配置位于 spec/fixtures/db/dynamic_finders.ymldownload-monitor-learndash-integration: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?v\d\.[\.\d])/ version: true Readme: path: readme.txt逐字段拆解字段值含义ChangeLog—该 finder 的名称key同时会作为动态生成的子类常量名classBodyPattern指定使用的动态查找器实现类本指纹属于「响应正文正则匹配」类型pathCHANGELOG.md需要请求的插件内相对路径启用 aggressive激进模式时访问pattern/\#\# (?v\d\.[\.\d])/用于从正文中捕获版本号的正则v为命名捕获组versiontrue标记该配置是版本指纹区别于Readme那种只用于收集候选文件名的配置注意同 slug 下还配置了Readme: path: readme.txt它没有version: true。这正是 WPScan 的设计细节Readme 不是真正的动态指纹它只是借助动态指纹系统来获取一个插件可能的文件名列表lib/wpscan/db/dynamic_finders/base.rb 的注释明确说明“The Readme is not put in there as its not a Real DF”而真正用于版本识别的是version: true的ChangeLog配置。二、模式一被动Passive——不额外发请求动态 finder 分为被动与激进两种执行路径由 lib/wpscan/finders/dynamic_finder/finder.rb 的基类控制def passive(opts {}) return if self.class::PATH # 配置了 path 的 finder 不做被动检测 homepage_result find(target.homepage_res, opts) return homepage_result unless homepage_result.nil? || homepage_result.empty? find(target.error_404_res, opts) end def aggressive(opts {}) return unless self.class::PATH # 没有 path 的 finder 不做激进检测 find(Browser.get(target.url(self.class::PATH)), opts) end对本样本的ChangeLog指纹而言由于配置了path: CHANGELOG.md被动模式直接跳过return if self.class::PATH不会在首页或 404 页面里寻找版本号激进模式才会发起GET {target_url}/wp-content/plugins/download-monitor-learndash-integration/CHANGELOG.md请求把响应正文交给BodyPattern解析。而Readme配置因为没有class、pattern只承担文件名提示功能不参与版本正则匹配。这种「被动零额外请求、激进按需请求」的设计保证了扫描器在默认被动枚举时不会引入多余流量。三、模式二激进Aggressive——请求真实文件并匹配正则当启用插件枚举如--enumerate p或--plugins-detection aggressive时WPScan 会按配置的path发起请求然后由BodyPattern实现类解析响应。核心逻辑在 lib/wpscan/finders/dynamic_finder/version/body_pattern.rbdef 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 响应直接返回nil目标站未安装该插件或文件被改名/删除非 404 时用配置的pattern对正文做正则匹配命中后取命名捕获组v作为版本号并记录interesting_entries包含有效 URL 与完整匹配片段作为取证信息写入扫描报告版本对象由 lib/wpscan/finders/dynamic_finder/version/finder.rb 的create_version构造默认置信度取子类常量CONFIDENCEBodyPattern为 60见 body_pattern.rb。针对本样本正则/\#\# (?v\d\.[\.\d])/匹配正文中的## 1.0.1、## 1.0.0最终返回1.0.1第一个命中。四、正则设计为什么这样写以及它的局限样本正则\#\# (?v\d\.[\.\d])反映了 Markdown 变更日志的通用形态\#\#匹配 Markdown 二级标题##本样本用的是###三级标题但##是###的前缀子串所以仍能命中版本号文本(?v...)命名捕获组\d\.[\.\d]匹配1.0.1这类「数字开头、点分隔」的版本串1.0.0、1.0.1均可只取第一个##开头的匹配——通常最新版本写在最上方符合绝大多数插件的变更日志惯例。对照组同仓库中另一插件 download-monitor-paid-membership-pro-integration 的正则/^\# (?v\d\.[\.\d])(?!.*\# \d\.[\.\d])/mi使用了行首锚定^、\#兼容#/##/###以及负向前瞻(?!...)来排除“标题中同时出现多个版本号”的干扰见 spec/fixtures/db/dynamic_finders.yml说明编写指纹时需针对具体文件的标题层级做微调。样本正则的局限也很明显属于可以如实说明的已知边界若变更日志把版本号写在## 1.0.1 (2022-09-23)这种带括号日期、且日期含.的标题里\d\.[\.\d]可能把日期也吃进去本样本的### 1.0.1: 23.09.2022中日期前有冒号和空格正则在1.0.1后的空格处停止恰好不受影响依赖文件存在且未改名的前提若站点把CHANGELOG.md改名或删除激进指纹即失效——这也正是 WPScan 同时配置多种 finder如Readme、BodyPattern、QueryParameter等互为补充的原因。五、源码链路从 YAML 配置到动态子类从配置到实际执行的完整调用链如下加载配置lib/wpscan/db/dynamic_finders/base.rb 将dynamic_finders.yml以 YAML 形式加载为all_df_data允许Regexp类型Plugin.df_data取其中的plugins段过滤版本指纹lib/wpscan/db/dynamic_finders/plugin.rb 的versions_finders_configs只收集带version: true的配置next unless config.key?(version)本样本的ChangeLog因此入选Readme被排除生成子类create_versions_finders先通过maybe_create_module按 slug 生成模块如DownloadMonitorLearndashIntegration再由 lib/wpscan/finders/dynamic_finder/finder.rb 的create_child_class用Class.new(self)动态创建子类把 YAML 中的path、pattern等写入子类常量执行匹配基类aggressive请求CHANGELOG.mdBodyPattern#find用子类常量PATTERN匹配并返回版本。类白名单在 lib/wpscan/db/dynamic_finders/base.rbComment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParser非白名单类会被拒绝防止通过外部 YAML 注入任意类。六、配套测试与验证方式WPScan 为每种动态 finder 都配有 RSpec 测试位于 spec/lib/finders/dynamic_finder/version/其中 body_pattern_spec.rb 覆盖了BodyPattern的命中与未命中分支。fixture 目录 spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/ 正是为这类测试提供真实抓取样本change_log/CHANGELOG.md保存了目标插件真实变更日志测试通过 mock HTTP 响应来验证正则能否正确提取1.0.1。本地验证正则是否可用无需跑完整扫描直接用 Ruby 单行即可复现ruby -e body File.read(spec/fixtures/dynamic_finders/plugin_version/download-monitor-learndash-integration/change_log/CHANGELOG.md); if body ~ /\#\# (?v\d\.[\.\d])/ then puts Regexp.last_match[:v]; end预期输出1.0.1与配置声明的版本指纹一致。若输出与预期不符通常需要调整pattern的标题层级或版本号字符类。七、把该方法推广到其他插件的实操清单基于上述链路为任意 WordPress 插件新增 CHANGELOG 版本指纹的通用步骤抓取该插件站内真实CHANGELOG.md或readme.txt放入spec/fixtures/dynamic_finders/plugin_version/slug/change_log/作为样本在dynamic_finders.yml的plugins段为该 slug 增加ChangeLog配置字段为class: BodyPattern、path: CHANGELOG.md、pattern带(?v...)命名捕获组、version: true按样本实际标题格式调整正则三级标题用\#\#\#、兼容多级用^\#、存在日期后缀时用负向前瞻排除多版本行用ruby -e单行脚本对照 fixture 样本先本地验证再补充body_pattern_spec.rb风格的 RSpec 用例联调验证wpscan --url 目标站 --enumerate p --plugins-detection aggressive观察报告中的found_by: Body Pattern与置信度 60。八、小结Download Monitor Learndash Integration 的 CHANGELOG 指纹是理解 WPScan 动态指纹体系的最佳入门样本它同时展示了version: true真版本指纹与Readme文件名提示两种配置形态串起了「YAML 配置 → 动态子类生成 → 被动/激进请求分流 → BodyPattern 正则匹配」的完整链路也暴露了正则写法对变更日志格式的敏感性与演进方向。掌握这套方法后你既能读懂 WPScan 内置的数千条插件指纹也能为扫描器贡献高质量的版本识别规则。赞分享网络安全漏洞扫描渗透测试应用安全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 插件版本指纹实战以 OptinMonster CHANGELOG 指纹为例WPScan 插件版本指纹实战以 OptinMonster CHANGELOG 指纹为例 本文以 WPScan 仓库中一份真实测试样例——OptinMonst网络安全漏洞扫描渗透测试应用安全CLIWPScan 动态指纹机制实战解析以 addy-autocomplete-woocommerce 的 CHANGELOG 版本检测为例WPScan 动态指纹机制实战解析以 addy autocomplete woocommerce 的 CHANGELOG 版本检测为例 WPScanWord网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本指纹识别实战以 nerd-wp CHANGELOG.md 测试样本为例解读 Change Log 动态指纹器WPScan 插件版本指纹识别实战以 nerd wp CHANGELOG.md 测试样本为例解读 Change Log 动态指纹器 本文以 WPScan网络安全漏洞扫描渗透测试应用安全CLI上一篇3分钟免费解锁Wand完整功能游戏修改器终极解决方案下一篇JuiceFS 如何用 fio 跑顺序读写基准测试并解读结果创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
