网络安全漏洞扫描渗透测试应用安全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机制——利用插件自身暴露在站点上的文件如readme.txt、CHANGELOG.md、.po翻译文件等作为指纹源。本文以仓库中custom-post-type-maker插件的 CHANGELOG.md 为具体样例完整讲解 WPScan 如何把一份普通的产品更新日志变成可用的被动版本指纹包括配置文件、正则规则、运行时调用链与测试验证。读完本文你将能理解 WPScan 动态发现体系的设计思路并能对照仓库自行添加或排查新的插件指纹。一、背景为什么用 CHANGELOG.md 做版本指纹WPScan 对插件/主题版本的识别策略分为两类主动方式Aggressive直接请求插件目录下的具体文件如readme.txt、style.css需要提前知道插件的 slug目录名。被动方式Passive只分析站点首页、404 页等页面中已经返回的内容HTML、脚本、样式引用不额外发起针对插件目录的请求更难被目标站点察觉。CHANGELOG.md恰好是两者皆可用的指纹源它通常位于插件根目录下wp-content/plugins/slug/CHANGELOG.md其头部会以## 1.1.6这类 Markdown 二级标题的形式标注最新版本号。只要站点没有删除该文件WPScan 就能据此推断插件版本。在 spec/fixtures/db/dynamic_finders.yml 中custom-post-type-maker的配置如下第 33288 行起custom-post-type-maker: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?v\d\.[\.\d])/ version: true这是 WPScan 通过 Dynamic Finder 体系做插件版本识别的标准配置形态字段含义字段值含义ChangeLog查找器名称由配置方自行命名通常与指纹源类型对应classBodyPattern使用的动态查找器实现类pathCHANGELOG.md指纹文件的相对路径有path即表明该查找器走主动aggressive模式pattern/\#\# (?v\d\.[\.\d])/从文件正文中抽取版本号的正则(?v...)命名捕获组是关键versiontrue该配置用于版本探测而非仅用于确认插件存在二、解读样例文件Custom Post Type Maker 的版本历史关联文档 CHANGELOG.md 记录的是 Graffino 开发、从 WordPress 官方插件仓库 fork 而来的 Custom Post Type Maker 插件的更新日志覆盖 1.0.0 至 1.1.6 共 11 个版本。其内容可归纳如下版本类型核心变更1.1.6修复修复选项卡tab导航问题1.1.5功能支持在 REST API 中展示自定义文章类型1.1.4功能支持在文章列表中展示自定义分类法taxonomy列1.1.3清理移除遗留的开发调试输出1.1.2修复允许register_post中在设为false时使用with_front参数1.1.1功能/修复/本地化自定义文章保存、插件激活/停用后自动刷新 rewrite 规则publicly_queryable默认改为true新增法语翻译1.1.0功能实现publicly_queryable选项1.0.4修复插件重命名以匹配 WP 插件目录1.0.3修复修正拼写错误1.0.2修复修复导致媒体库无法加载的undefined错误1.0.1兼容兼容未来版本的 WordPress1.0.0功能/修复/fork支持选择 DashIcons 作为自定义文章类型图标修复add_utility_page在 4.5.2 中的废弃提示fork 自官方插件这份日志之所以能成为指纹是因为它严格遵守## 版本号的 Markdown 标题格式。WPScan 的正则/\#\# (?v\d\.[\.\d])/恰好命中## 1.1.6这样的行捕获组v得到1.1.6。由于是逐行匹配、且1.1.6是文件中第一个出现的版本标题也是最新的识别结果即为当前安装版本。三、运行时原理BodyPattern 查找器与调用链配置中的class: BodyPattern对应 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb。该类的核心逻辑非常简洁class 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要点如下PATTERN与CONFIDENCE子类常量child class constants机制——PATTERN: nil表示由外部配置注入正则CONFIDENCE: 60是默认置信度即通过该方式识别出的版本默认置信度为 60create_version时通过version_finding_opts写入见 version/finder.rb。404 过滤响应码为 404 时不参与匹配避免把站点自定义 404 页面误判为插件文件内容。命名捕获组Regexp.last_match[:v]直接取出正则中(?v...)捕获的版本号字符串并附带interesting_entries记录实际匹配内容供最终报告展示证据。3.1 配置如何变成类运行期lib/wpscan/db/dynamic_finders/plugin.rb 的create_versions_finders(slug)会遍历versions_finders_configs仅收集config.key?(version)为真的条目对每个查找器调用version_finder_super_class(klass).create_child_class(mod, finder_class.to_sym, config)。而 lib/wpscan/finders/dynamic_finder/finder.rb 中的create_child_class会把配置值注入子类常量class_constants.each do |key, value| const_set(key, config[key.downcase.to_s] || value) end即PATTERN被赋值为配置里的patternPATH被赋值为CHANGELOG.md最终生成一个针对该插件的专用查找器类注册到WPScan::Finders::DynamicFinder::WpItemVersion::CustomPostTypeMaker模块下maybe_create_module负责按 slug 自动创建模块见 plugin.rb 第 63 行。3.2 被动与主动的执行路径同一个查找器类同时具备两种模式由基类 finder.rb 统一调度passive被动当PATH为空时生效——只匹配目标首页响应target.homepage_res与 404 页响应target.error_404_res不发起新请求。aggressive主动当PATH存在时生效——直接请求target.url(self.class::PATH)即https://站点/wp-content/plugins/custom-post-type-maker/CHANGELOG.md再交给find匹配。由于custom-post-type-maker配置中明确写了path: CHANGELOG.md该指纹默认以主动模式工作。这与 WpItemVersion 中声明的BodyPattern子类注册相呼应——注意该模块中还预置了Comment、Xpath、HeaderPattern、JavascriptVar、QueryParameter、ConfigParser等其他查找器类型共同构成 WPScan 的插件指纹查找器家族。3.3 允许的查找器类型约束lib/wpscan/db/dynamic_finders/base.rb 中allowed_classes白名单限定了可用的动态查找器类allowed_classes || %i[Comment Xpath HeaderPattern BodyPattern JavascriptVar QueryParameter ConfigParser]BodyPattern在此白名单内。当配置文件里出现白名单之外的class时create_versions_finders会直接跳过next unless allowed_classes.include?(klass.to_sym)而非抛异常——这一设计让旧版 WPScan 在数据库更新后仍能安全扫描代码注释明确说明该意图见 plugin.rb 第 88 行附近。四、验证与测试fixtures 如何支撑可信度仓库中该 CHANGELOG.md 被放置在spec/fixtures/dynamic_finders/plugin_version/目录下说明它同时扮演测试夹具的角色集成测试通过模拟站点返回该文件内容验证 BodyPattern 查找器能否正确抽取1.1.6。对应的单元测试位于 spec/lib/finders/dynamic_finder/version/body_pattern_spec.rb。在真实扫描场景中上述识别结果会进一步与 spec/fixtures/db/metadata.json 所代表的本地方漏洞/元数据数据库比对若1.1.6并非最新版本、或存在已知漏洞条目WPScan 就会在报告中输出对应的漏洞告警与版本差异提示。动态查找器解决的是站点上有什么、是什么版本的问题而漏洞匹配解决的是这个版本有什么风险的问题两者在 lib/wpscan/db/dynamic_finders/plugin.rb 与 lib/wpscan/vulnerable.rb 中完成衔接。五、实操启示如何为其他插件补充同款指纹理解了custom-post-type-maker的配置后可以为任何遵循## x.y.z日志格式的插件添加同款指纹只需三步确认日志格式确保插件根目录存在CHANGELOG.md且版本行形如## 1.2.3必要时同步检查readme.txt中的Stable tag:两者可互为印证。写配置在 spec/fixtures/db/dynamic_finders.yml 中以插件 slug 为键新增条目复用 BodyPattern 与path: CHANGELOG.md并根据日志风格微调pattern例如同时支持###三级标题时可将正则放宽为/^#\s(?v\d\.\d\.\d)/。补充夹具与测试把样例日志放入spec/fixtures/dynamic_finders/plugin_version/slug/并仿照现有 spec 验证能正确命中版本号。需要注意正则的(?v...)命名捕获组是 WPScan 抽取版本号的既定契约改写正则时务必保留同时保持version: true否则该配置不会被versions_finders_configs收集也就无法参与版本探测。结语一份看似普通的CHANGELOG.md在 WPScan 的动态发现体系中扮演了被动指纹源的角色YAML 配置声明规则BodyPattern类负责抽取版本create_child_class负责运行时注入versions_finders_configs负责筛选version: true的条目最终与漏洞数据库联动输出安全结论。理解这条链路是深入使用或二次开发 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 动态指纹实战从 Post Type Switcher 的 CHANGELOG.md 识别 WordPress 插件版本WPScan 动态指纹实战从 Post Type Switcher 的 CHANGELOG.md 识别 WordPress 插件版本 导读 本文以 WPSca网络安全漏洞扫描渗透测试应用安全CLIWPScan 基于插件 CHANGELOG.md 的版本指纹识别以 comments-link-optimization 为例WPScan 基于插件 CHANGELOG.md 的版本指纹识别以 comments link optimization 为例 导读 本文以 WPScan 仓网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本指纹识别实战以 Colissimo 配送插件的 changelog.md 为例WPScan 插件版本指纹识别实战以 Colissimo 配送插件的 changelog.md 为例 导读 本文以 WPScan 仓库中收录的 colissi网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WPScan 插件版本被动指纹识别：以 Custom Post Type Maker 的 CHANGELOG.md 为例
网络安全漏洞扫描渗透测试应用安全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机制——利用插件自身暴露在站点上的文件如readme.txt、CHANGELOG.md、.po翻译文件等作为指纹源。本文以仓库中custom-post-type-maker插件的 CHANGELOG.md 为具体样例完整讲解 WPScan 如何把一份普通的产品更新日志变成可用的被动版本指纹包括配置文件、正则规则、运行时调用链与测试验证。读完本文你将能理解 WPScan 动态发现体系的设计思路并能对照仓库自行添加或排查新的插件指纹。一、背景为什么用 CHANGELOG.md 做版本指纹WPScan 对插件/主题版本的识别策略分为两类主动方式Aggressive直接请求插件目录下的具体文件如readme.txt、style.css需要提前知道插件的 slug目录名。被动方式Passive只分析站点首页、404 页等页面中已经返回的内容HTML、脚本、样式引用不额外发起针对插件目录的请求更难被目标站点察觉。CHANGELOG.md恰好是两者皆可用的指纹源它通常位于插件根目录下wp-content/plugins/slug/CHANGELOG.md其头部会以## 1.1.6这类 Markdown 二级标题的形式标注最新版本号。只要站点没有删除该文件WPScan 就能据此推断插件版本。在 spec/fixtures/db/dynamic_finders.yml 中custom-post-type-maker的配置如下第 33288 行起custom-post-type-maker: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /\#\# (?v\d\.[\.\d])/ version: true这是 WPScan 通过 Dynamic Finder 体系做插件版本识别的标准配置形态字段含义字段值含义ChangeLog查找器名称由配置方自行命名通常与指纹源类型对应classBodyPattern使用的动态查找器实现类pathCHANGELOG.md指纹文件的相对路径有path即表明该查找器走主动aggressive模式pattern/\#\# (?v\d\.[\.\d])/从文件正文中抽取版本号的正则(?v...)命名捕获组是关键versiontrue该配置用于版本探测而非仅用于确认插件存在二、解读样例文件Custom Post Type Maker 的版本历史关联文档 CHANGELOG.md 记录的是 Graffino 开发、从 WordPress 官方插件仓库 fork 而来的 Custom Post Type Maker 插件的更新日志覆盖 1.0.0 至 1.1.6 共 11 个版本。其内容可归纳如下版本类型核心变更1.1.6修复修复选项卡tab导航问题1.1.5功能支持在 REST API 中展示自定义文章类型1.1.4功能支持在文章列表中展示自定义分类法taxonomy列1.1.3清理移除遗留的开发调试输出1.1.2修复允许register_post中在设为false时使用with_front参数1.1.1功能/修复/本地化自定义文章保存、插件激活/停用后自动刷新 rewrite 规则publicly_queryable默认改为true新增法语翻译1.1.0功能实现publicly_queryable选项1.0.4修复插件重命名以匹配 WP 插件目录1.0.3修复修正拼写错误1.0.2修复修复导致媒体库无法加载的undefined错误1.0.1兼容兼容未来版本的 WordPress1.0.0功能/修复/fork支持选择 DashIcons 作为自定义文章类型图标修复add_utility_page在 4.5.2 中的废弃提示fork 自官方插件这份日志之所以能成为指纹是因为它严格遵守## 版本号的 Markdown 标题格式。WPScan 的正则/\#\# (?v\d\.[\.\d])/恰好命中## 1.1.6这样的行捕获组v得到1.1.6。由于是逐行匹配、且1.1.6是文件中第一个出现的版本标题也是最新的识别结果即为当前安装版本。三、运行时原理BodyPattern 查找器与调用链配置中的class: BodyPattern对应 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb。该类的核心逻辑非常简洁class 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要点如下PATTERN与CONFIDENCE子类常量child class constants机制——PATTERN: nil表示由外部配置注入正则CONFIDENCE: 60是默认置信度即通过该方式识别出的版本默认置信度为 60create_version时通过version_finding_opts写入见 version/finder.rb。404 过滤响应码为 404 时不参与匹配避免把站点自定义 404 页面误判为插件文件内容。命名捕获组Regexp.last_match[:v]直接取出正则中(?v...)捕获的版本号字符串并附带interesting_entries记录实际匹配内容供最终报告展示证据。3.1 配置如何变成类运行期lib/wpscan/db/dynamic_finders/plugin.rb 的create_versions_finders(slug)会遍历versions_finders_configs仅收集config.key?(version)为真的条目对每个查找器调用version_finder_super_class(klass).create_child_class(mod, finder_class.to_sym, config)。而 lib/wpscan/finders/dynamic_finder/finder.rb 中的create_child_class会把配置值注入子类常量class_constants.each do |key, value| const_set(key, config[key.downcase.to_s] || value) end即PATTERN被赋值为配置里的patternPATH被赋值为CHANGELOG.md最终生成一个针对该插件的专用查找器类注册到WPScan::Finders::DynamicFinder::WpItemVersion::CustomPostTypeMaker模块下maybe_create_module负责按 slug 自动创建模块见 plugin.rb 第 63 行。3.2 被动与主动的执行路径同一个查找器类同时具备两种模式由基类 finder.rb 统一调度passive被动当PATH为空时生效——只匹配目标首页响应target.homepage_res与 404 页响应target.error_404_res不发起新请求。aggressive主动当PATH存在时生效——直接请求target.url(self.class::PATH)即https://站点/wp-content/plugins/custom-post-type-maker/CHANGELOG.md再交给find匹配。由于custom-post-type-maker配置中明确写了path: CHANGELOG.md该指纹默认以主动模式工作。这与 WpItemVersion 中声明的BodyPattern子类注册相呼应——注意该模块中还预置了Comment、Xpath、HeaderPattern、JavascriptVar、QueryParameter、ConfigParser等其他查找器类型共同构成 WPScan 的插件指纹查找器家族。3.3 允许的查找器类型约束lib/wpscan/db/dynamic_finders/base.rb 中allowed_classes白名单限定了可用的动态查找器类allowed_classes || %i[Comment Xpath HeaderPattern BodyPattern JavascriptVar QueryParameter ConfigParser]BodyPattern在此白名单内。当配置文件里出现白名单之外的class时create_versions_finders会直接跳过next unless allowed_classes.include?(klass.to_sym)而非抛异常——这一设计让旧版 WPScan 在数据库更新后仍能安全扫描代码注释明确说明该意图见 plugin.rb 第 88 行附近。四、验证与测试fixtures 如何支撑可信度仓库中该 CHANGELOG.md 被放置在spec/fixtures/dynamic_finders/plugin_version/目录下说明它同时扮演测试夹具的角色集成测试通过模拟站点返回该文件内容验证 BodyPattern 查找器能否正确抽取1.1.6。对应的单元测试位于 spec/lib/finders/dynamic_finder/version/body_pattern_spec.rb。在真实扫描场景中上述识别结果会进一步与 spec/fixtures/db/metadata.json 所代表的本地方漏洞/元数据数据库比对若1.1.6并非最新版本、或存在已知漏洞条目WPScan 就会在报告中输出对应的漏洞告警与版本差异提示。动态查找器解决的是站点上有什么、是什么版本的问题而漏洞匹配解决的是这个版本有什么风险的问题两者在 lib/wpscan/db/dynamic_finders/plugin.rb 与 lib/wpscan/vulnerable.rb 中完成衔接。五、实操启示如何为其他插件补充同款指纹理解了custom-post-type-maker的配置后可以为任何遵循## x.y.z日志格式的插件添加同款指纹只需三步确认日志格式确保插件根目录存在CHANGELOG.md且版本行形如## 1.2.3必要时同步检查readme.txt中的Stable tag:两者可互为印证。写配置在 spec/fixtures/db/dynamic_finders.yml 中以插件 slug 为键新增条目复用 BodyPattern 与path: CHANGELOG.md并根据日志风格微调pattern例如同时支持###三级标题时可将正则放宽为/^#\s(?v\d\.\d\.\d)/。补充夹具与测试把样例日志放入spec/fixtures/dynamic_finders/plugin_version/slug/并仿照现有 spec 验证能正确命中版本号。需要注意正则的(?v...)命名捕获组是 WPScan 抽取版本号的既定契约改写正则时务必保留同时保持version: true否则该配置不会被versions_finders_configs收集也就无法参与版本探测。结语一份看似普通的CHANGELOG.md在 WPScan 的动态发现体系中扮演了被动指纹源的角色YAML 配置声明规则BodyPattern类负责抽取版本create_child_class负责运行时注入versions_finders_configs负责筛选version: true的条目最终与漏洞数据库联动输出安全结论。理解这条链路是深入使用或二次开发 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 动态指纹实战从 Post Type Switcher 的 CHANGELOG.md 识别 WordPress 插件版本WPScan 动态指纹实战从 Post Type Switcher 的 CHANGELOG.md 识别 WordPress 插件版本 导读 本文以 WPSca网络安全漏洞扫描渗透测试应用安全CLIWPScan 基于插件 CHANGELOG.md 的版本指纹识别以 comments-link-optimization 为例WPScan 基于插件 CHANGELOG.md 的版本指纹识别以 comments link optimization 为例 导读 本文以 WPScan 仓网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本指纹识别实战以 Colissimo 配送插件的 changelog.md 为例WPScan 插件版本指纹识别实战以 Colissimo 配送插件的 changelog.md 为例 导读 本文以 WPScan 仓库中收录的 colissi网络安全漏洞扫描渗透测试应用安全CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考