网络安全漏洞扫描渗透测试应用安全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 安全扫描器中一项核心能力通过插件自带的CHANGELOG.md文件实现版本号的自动识别。文章以仓库中的真实测试夹具 spec/fixtures/dynamic_finders/plugin_version/formgimp/change_log/CHANGELOG.md 为主体从夹具内容、检测规则配置、底层 BodyPattern 实现到测试验证逐层展开。读完本文你将理解 WPScan 的 Change LogAggressive Detection 版本发现是如何工作的并掌握为任意插件配置同类检测规则所需的知识。一、夹具本体formgimp 的 CHANGELOG.md 里有什么该夹具是一份遵循 Keep a Changelog 惯例编写的插件更新日志其核心内容如下声明遵循 Keep a Changelog 格式与 Semantic Versioning语义化版本定义了五类变更标签Change TagsAdded新功能、Changed既有功能变更、Deprecated即将移除、Removed已移除、Fixed缺陷修复与Security安全漏洞给出了唯一一个版本条目## 1.0.5 - 2020-02-19其下记录了AddedSession initialization会话初始化、Shortcode to form list/edit views表单列表/编辑视图的短代码Changed管理后台菜单中去掉重复的 FormGimp 子菜单项路径赋值由get_template_xxx改为get_stylesheet_xxx以支持子主题child theme。这份文件本身是 FormGimp 插件的真实发布记录但在 WPScan 仓库中它扮演的是测试样本角色扫描器需要从这样一份更新日志中准确提取出该插件当前版本是 1.0.5这一结论。二、从日志到规则dynamic_finders.yml 中的 formgimp 配置WPScan 将这类从插件自带文件里找版本的检测能力称为Dynamic Finders动态发现器所有插件的检测规则集中维护在 spec/fixtures/db/dynamic_finders.yml运行时对应lib/db/dynamic_finders.yml。其中 formgimp 的完整配置为formgimp: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /^\#\# (?v\d\.[\.\d]) \- [\d\-](?!.*\#\# \d\.[\.\d] \- [\d\-])/mi version: true Readme: path: README.txt逐字段解读字段值含义ChangeLog发现器名称对应一个Change Log 版本发现器classBodyPattern指定使用 BodyPattern 这一发现器实现类下文详解pathCHANGELOG.md需要探测的插件内文件路径最终请求wp-content/plugins/formgimp/CHANGELOG.mdpattern正则表达式用于在文件正文中定位版本号其中(?v...)是版本号的命名捕获组versiontrue标记该发现器用于产出插件版本号这条正则^\#\# (?v\d\.[\.\d]) \- [\d\-](?!.*\#\# \d\.[\.\d] \- [\d\-])的含义可以拆解为^\#\#匹配行首的##Keep a Changelog 的版本标题格式(?v\d\.[\.\d])捕获形如1.0.5的版本号并命名为v\- [\d\-]匹配- 2020-02-19这样的发布日期(?!.*\#\# \d\.[\.\d] \- [\d\-])是负向前瞻要求这是文件中最后一个最新版本标题——这正是取当前版本而非历史版本的关键逻辑修饰符mi表示多行与忽略大小写匹配。值得注意该配置没有显式指定confidence因此使用 BodyPattern 实现类的默认置信度 60详见下一节。三、底层原理BodyPattern 版本发现器如何工作配置中的class: BodyPattern指向 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb。其核心逻辑如下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从源码可以提炼出三个实现事实默认置信度 60BodyPattern 类通过child_class_constants为子类预设CONFIDENCE: 60除非配置文件显式覆盖否则该发现器产出的版本置信度为 60404 直接排除只有当目标文件存在响应码非 404且正文匹配正则时才继续命名捕获组取版本Regexp.last_match[:v]取出正则中(?v...)捕获的版本号并将其与匹配上下文effective_url与完整匹配串一起作为interesting_entries记录便于审计与复现。版本对象的组装由其基类 lib/wpscan/finders/dynamic_finder/version/finder.rb 完成create_version会构造Model::Version并自动补全found_by发现方式与confidence字段——这也是最终输出中 found_by: Change Log (Aggressive Detection) 的来源。四、规则如何被加载与实例化动态类的生成链路从一份 YAML 规则到一个可运行的 Ruby 发现器类链路在 lib/wpscan/db/dynamic_finders/plugin.rb 中实现finders_configs(finder_class, aggressive: true)以path是否为空区分 aggressive需要请求具体文件路径与 passive 两类配置formgimp 的ChangeLog带path因此属于 Aggressive Detectioncreate_versions_finders(slug)读取versions_finders_configs中该 slug 的配置将class: BodyPattern解析为WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern并为 formgimp 动态创建子类传入PATTERN与pathmaybe_create_module(slug)将 slug 如formgimp规范化为Finders::PluginVersion::Formgimp模块且同类重复创建时不会抛错见 spec/lib/db/dynamic_finders/plugin_spec.rb 中create_versions_finders的幂等性测试。底层合法发现器类别由 lib/wpscan/db/dynamic_finders/base.rb 的allowed_classes白名单约束包括Comment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParser越界类别会被拒绝。五、测试与验证expected.yml 中的期望结果该夹具的标准答案记录在 spec/fixtures/dynamic_finders/expected.yml 中formgimp: ChangeLog: number: 1.0.5 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/formgimp/CHANGELOG.md, Match: ## 1.0.5 - 2020-02-19这份期望数据验证了两点一是版本号提取结果确为1.0.5正则可命中且负向前瞻保证取的是最新条目二是interesting_entries中记录的匹配内容## 1.0.5 - 2020-02-19与夹具文件第一行版本标题完全一致证明请求路径CHANGELOG.md与正则模式的配合是正确的。同一目录下其他插件的ChangeLog配置如 2fas、404-page、404-page-editor 等还展示了changelog.txt、CHANGELOG.txt等不同文件名与各自正则风格可作为横向参照。六、实战启示如何为新插件编写 Change Log 检测规则结合以上分析为某个新插件添加从 CHANGELOG 文件识别版本的能力可归纳为三步确认文件与格式插件根目录存在更新日志常见CHANGELOG.md/changelog.txt且版本以类似## 1.0.5 - 2020-02-19或 1.0.5的标题行开头编写配置条目在 dynamic_finders.yml 中为该 slug 增加ChangeLog节点指定class: BodyPattern、path与pattern并将版本号放入(?v...)命名捕获组version: true若文件内存在多个版本标题务必用负向前瞻(?!...)锚定最后一个标题提供测试夹具与期望在spec/fixtures/dynamic_finders/plugin_version/slug/下放置真实的日志样本并在expected.yml中登记期望的number与interesting_entries与仓库既有验证体系保持一致。需要说明的边界这种检测依赖插件日志的文件名、标题格式与存放位置且属于 Aggressive Detection需逐插件发起文件请求因此只对维护规范更新日志的插件有效版本识别结果通常以置信度 60 呈现实际扫描中常与 readme.txt 的 Stable Tag置信度 80等来源交叉印证参见 spec/app/finders/plugin_version/readme_spec.rb 中changelog_section与stable_tag的对比测试。这正是 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 插件版本动态检测实战以 plug-payments-gateway 插件的 Changelog 测试夹具为例WPScan 插件版本动态检测实战以 plug payments gateway 插件的 Changelog 测试夹具为例 本文以 WPScan 仓库中的一个网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本检测实例以 MultiSafepay CHANGELOG.md 为例解析 ChangeLog 动态指纹机制WPScan 插件版本检测实例以 MultiSafepay CHANGELOG.md 为例解析 ChangeLog 动态指纹机制 本文以 WPScan 测试夹网络安全漏洞扫描渗透测试应用安全CLI从 adshares 插件 CHANGELOG 看 WPScan 的 ChangeLog 动态版本检测机制从 adshares 插件 CHANGELOG 看 WPScan 的 ChangeLog 动态版本检测机制 导读 本文以 WPScan 仓库中 adshares网络安全漏洞扫描渗透测试应用安全CLI上一篇gh_mirrors/tr/transform用户行为分析优化产品体验下一篇Whenever gem的错误告警系统Ruby任务异常的及时响应创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WPScan 插件版本检测实战：以 formgimp CHANGELOG 夹具解析 Change Log 动态发现机制
网络安全漏洞扫描渗透测试应用安全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 安全扫描器中一项核心能力通过插件自带的CHANGELOG.md文件实现版本号的自动识别。文章以仓库中的真实测试夹具 spec/fixtures/dynamic_finders/plugin_version/formgimp/change_log/CHANGELOG.md 为主体从夹具内容、检测规则配置、底层 BodyPattern 实现到测试验证逐层展开。读完本文你将理解 WPScan 的 Change LogAggressive Detection 版本发现是如何工作的并掌握为任意插件配置同类检测规则所需的知识。一、夹具本体formgimp 的 CHANGELOG.md 里有什么该夹具是一份遵循 Keep a Changelog 惯例编写的插件更新日志其核心内容如下声明遵循 Keep a Changelog 格式与 Semantic Versioning语义化版本定义了五类变更标签Change TagsAdded新功能、Changed既有功能变更、Deprecated即将移除、Removed已移除、Fixed缺陷修复与Security安全漏洞给出了唯一一个版本条目## 1.0.5 - 2020-02-19其下记录了AddedSession initialization会话初始化、Shortcode to form list/edit views表单列表/编辑视图的短代码Changed管理后台菜单中去掉重复的 FormGimp 子菜单项路径赋值由get_template_xxx改为get_stylesheet_xxx以支持子主题child theme。这份文件本身是 FormGimp 插件的真实发布记录但在 WPScan 仓库中它扮演的是测试样本角色扫描器需要从这样一份更新日志中准确提取出该插件当前版本是 1.0.5这一结论。二、从日志到规则dynamic_finders.yml 中的 formgimp 配置WPScan 将这类从插件自带文件里找版本的检测能力称为Dynamic Finders动态发现器所有插件的检测规则集中维护在 spec/fixtures/db/dynamic_finders.yml运行时对应lib/db/dynamic_finders.yml。其中 formgimp 的完整配置为formgimp: ChangeLog: class: BodyPattern path: CHANGELOG.md pattern: !ruby/regexp /^\#\# (?v\d\.[\.\d]) \- [\d\-](?!.*\#\# \d\.[\.\d] \- [\d\-])/mi version: true Readme: path: README.txt逐字段解读字段值含义ChangeLog发现器名称对应一个Change Log 版本发现器classBodyPattern指定使用 BodyPattern 这一发现器实现类下文详解pathCHANGELOG.md需要探测的插件内文件路径最终请求wp-content/plugins/formgimp/CHANGELOG.mdpattern正则表达式用于在文件正文中定位版本号其中(?v...)是版本号的命名捕获组versiontrue标记该发现器用于产出插件版本号这条正则^\#\# (?v\d\.[\.\d]) \- [\d\-](?!.*\#\# \d\.[\.\d] \- [\d\-])的含义可以拆解为^\#\#匹配行首的##Keep a Changelog 的版本标题格式(?v\d\.[\.\d])捕获形如1.0.5的版本号并命名为v\- [\d\-]匹配- 2020-02-19这样的发布日期(?!.*\#\# \d\.[\.\d] \- [\d\-])是负向前瞻要求这是文件中最后一个最新版本标题——这正是取当前版本而非历史版本的关键逻辑修饰符mi表示多行与忽略大小写匹配。值得注意该配置没有显式指定confidence因此使用 BodyPattern 实现类的默认置信度 60详见下一节。三、底层原理BodyPattern 版本发现器如何工作配置中的class: BodyPattern指向 lib/wpscan/finders/dynamic_finder/version/body_pattern.rb。其核心逻辑如下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从源码可以提炼出三个实现事实默认置信度 60BodyPattern 类通过child_class_constants为子类预设CONFIDENCE: 60除非配置文件显式覆盖否则该发现器产出的版本置信度为 60404 直接排除只有当目标文件存在响应码非 404且正文匹配正则时才继续命名捕获组取版本Regexp.last_match[:v]取出正则中(?v...)捕获的版本号并将其与匹配上下文effective_url与完整匹配串一起作为interesting_entries记录便于审计与复现。版本对象的组装由其基类 lib/wpscan/finders/dynamic_finder/version/finder.rb 完成create_version会构造Model::Version并自动补全found_by发现方式与confidence字段——这也是最终输出中 found_by: Change Log (Aggressive Detection) 的来源。四、规则如何被加载与实例化动态类的生成链路从一份 YAML 规则到一个可运行的 Ruby 发现器类链路在 lib/wpscan/db/dynamic_finders/plugin.rb 中实现finders_configs(finder_class, aggressive: true)以path是否为空区分 aggressive需要请求具体文件路径与 passive 两类配置formgimp 的ChangeLog带path因此属于 Aggressive Detectioncreate_versions_finders(slug)读取versions_finders_configs中该 slug 的配置将class: BodyPattern解析为WPScan::Finders::DynamicFinder::WpItemVersion::BodyPattern并为 formgimp 动态创建子类传入PATTERN与pathmaybe_create_module(slug)将 slug 如formgimp规范化为Finders::PluginVersion::Formgimp模块且同类重复创建时不会抛错见 spec/lib/db/dynamic_finders/plugin_spec.rb 中create_versions_finders的幂等性测试。底层合法发现器类别由 lib/wpscan/db/dynamic_finders/base.rb 的allowed_classes白名单约束包括Comment、Xpath、HeaderPattern、BodyPattern、JavascriptVar、QueryParameter、ConfigParser越界类别会被拒绝。五、测试与验证expected.yml 中的期望结果该夹具的标准答案记录在 spec/fixtures/dynamic_finders/expected.yml 中formgimp: ChangeLog: number: 1.0.5 found_by: Change Log (Aggressive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/formgimp/CHANGELOG.md, Match: ## 1.0.5 - 2020-02-19这份期望数据验证了两点一是版本号提取结果确为1.0.5正则可命中且负向前瞻保证取的是最新条目二是interesting_entries中记录的匹配内容## 1.0.5 - 2020-02-19与夹具文件第一行版本标题完全一致证明请求路径CHANGELOG.md与正则模式的配合是正确的。同一目录下其他插件的ChangeLog配置如 2fas、404-page、404-page-editor 等还展示了changelog.txt、CHANGELOG.txt等不同文件名与各自正则风格可作为横向参照。六、实战启示如何为新插件编写 Change Log 检测规则结合以上分析为某个新插件添加从 CHANGELOG 文件识别版本的能力可归纳为三步确认文件与格式插件根目录存在更新日志常见CHANGELOG.md/changelog.txt且版本以类似## 1.0.5 - 2020-02-19或 1.0.5的标题行开头编写配置条目在 dynamic_finders.yml 中为该 slug 增加ChangeLog节点指定class: BodyPattern、path与pattern并将版本号放入(?v...)命名捕获组version: true若文件内存在多个版本标题务必用负向前瞻(?!...)锚定最后一个标题提供测试夹具与期望在spec/fixtures/dynamic_finders/plugin_version/slug/下放置真实的日志样本并在expected.yml中登记期望的number与interesting_entries与仓库既有验证体系保持一致。需要说明的边界这种检测依赖插件日志的文件名、标题格式与存放位置且属于 Aggressive Detection需逐插件发起文件请求因此只对维护规范更新日志的插件有效版本识别结果通常以置信度 60 呈现实际扫描中常与 readme.txt 的 Stable Tag置信度 80等来源交叉印证参见 spec/app/finders/plugin_version/readme_spec.rb 中changelog_section与stable_tag的对比测试。这正是 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 插件版本动态检测实战以 plug-payments-gateway 插件的 Changelog 测试夹具为例WPScan 插件版本动态检测实战以 plug payments gateway 插件的 Changelog 测试夹具为例 本文以 WPScan 仓库中的一个网络安全漏洞扫描渗透测试应用安全CLIWPScan 插件版本检测实例以 MultiSafepay CHANGELOG.md 为例解析 ChangeLog 动态指纹机制WPScan 插件版本检测实例以 MultiSafepay CHANGELOG.md 为例解析 ChangeLog 动态指纹机制 本文以 WPScan 测试夹网络安全漏洞扫描渗透测试应用安全CLI从 adshares 插件 CHANGELOG 看 WPScan 的 ChangeLog 动态版本检测机制从 adshares 插件 CHANGELOG 看 WPScan 的 ChangeLog 动态版本检测机制 导读 本文以 WPScan 仓库中 adshares网络安全漏洞扫描渗透测试应用安全CLI上一篇gh_mirrors/tr/transform用户行为分析优化产品体验下一篇Whenever gem的错误告警系统Ruby任务异常的及时响应创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考