企业官网建设流程全解析

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI

本文以 WPScan 仓库中的 WordPress 插件 Media Credit 的 CHANGELOG.md 为线索，讲解一份看似普通的变更日志如何同时扮演「插件历史文档」与「安全扫描版本指纹」双重角色：前半部分梳理该文档所记载的插件能力演进，后半部分结合 expected.yml 与动态查找器源码，说明 WPScan 如何借助 ChangeLog 与 Query Parameter 两类查找器对这类插件进行版本识别。读完本文，你将掌握 WPScan 动态版本检测的基本原理，并理解 CHANGELOG 类文件在被动/主动检测中的实际用法。

一、文档定位：一份被扫描器当作指纹的变更日志

Media Credit 是一款为 WordPress 媒体附件（图片等）添加「版权署名（credit）」能力的插件，允许将媒体与 WordPress 用户关联、为媒体设置作者署名链接，或直接填写自由文本署名。其变更日志覆盖了从 0.5（2010 年 3 月）到 4.0.3（2019 年 3 月）的完整版本历程。

在 WPScan 仓库中，这份文档被收纳为动态查找器（Dynamic Finders）的测试夹具，路径为 spec/fixtures/dynamic_finders/plugin_version/media-credit/change_log/CHANGELOG.md。其目录结构plugin_version/<slug>/change_log/对应了插件的变更日志指纹，而 spec/fixtures/dynamic_finders/expected.yml 中记录了该插件的两条版本识别断言：

media-credit: QueryParameter: number: 3.1.7 found_by: Query Parameter (Passive Detection) interesting_entries: - http://wp.lab/wp-content/plugins/media-credit/public/css/media-credit.css?ver=3.1.7 - http://wp.lab/wp-content/plugins/media-credit/public/css/media-credit.min.css?ver=3.1.7 confidence: 20 ChangeLog: number: 4.0.3 found_by: Change Log (Aggressive Detection) interesting_entries: - 'http://wp.lab/wp-content/plugins/media-credit/CHANGELOG.md, Match: ''## 4.0.3'''

可见，同一份变更日志在 WPScan 中被同时用于两处版本探测：一是通过插件 CSS 文件的?ver=查询参数被动识别出 3.1.7，二是主动请求插件目录下的CHANGELOG.md，匹配其中的版本标题行## 4.0.3。这正是「文档本身即指纹」的设计思想：CHANGELOG 的版本号格式（## x.y.z）足够稳定且具有唯一性，非常适合作为版本判定的锚点。

二、CHANGELOG 记载的核心能力：为 WordPress 媒体加上署名

从变更日志可以还原出 Media Credit 插件的核心功能模型，这也是理解其为何会产生如此多版本迭代的背景知识。

2.1 署名的三种形态

• 用户署名（default credit）：将附件作者作为默认署名，可被「Do not credit images to WordPress users」等选项关闭（4.0.2、4.0.0 修复了关闭默认署名后设置特色图、使用用户名作为自由文本署名的问题）。
• 自由文本署名（freeform credit）：不受限于用户体系，任意文本均可作为署名（1.1.2、3.1.6 修复了空署名返回''、以及先选用户再填自由文本的边界情况）。
• 链接化署名：从 2.5.0 起在短代码与图形界面中加入 URL 参数，2.6.0 起支持 Credit URL 覆盖自动生成的作者链接。

2.2 署名与附件的同步机制

这是插件自 1.0 起就持续打磨的核心链路：在媒体库（Media Library）中修改署名后，需同步更新到所有引用了该媒体的文章内。1.1.1 修复「媒体库更新能正确同步到文章内」、1.1 支持跨 WP 用户与非用户场景的安全更新、3.1.4 修复「编辑图片详情时模型同步」，再到 4.0.2 修复「开启不署名给 WP 用户时特色图无法正常设置」，这一系列条目清晰地勾勒出「媒体元数据 → 文章短代码渲染」的同步管线。

2.3 特色图（Featured Image）署名

特色图署名是 3.0.0 引入的能力，此后持续修补：3.1.5 防止特色图署名中出现非法的链接嵌套（默认不输出<a>，可通过add_filter( 'media_credit_post_thumbnail_include_links', __return_true );恢复旧行为）；3.1.6 让「Do not display default credit」对特色图生效；4.0.3 修复署名应归属于特色图本身而非父文章的回归。

三、4.0 时代：REST API、过滤器钩子与块编辑器

4.0.0（2019 年 3 月 11 日）是一次标志性重构，变更日志将其核心变化浓缩为以下要点，可作为插件能力边界的权威依据：

• 完整 REST API 支持（读写）：插件数据可通过 WordPress REST API 读取与写入，为无头（headless）场景与第三方客户端集成铺路。
• 新过滤器钩子：media_credit_new_attachment_default用于为新附件设置自定义默认署名；media_credit_placeholder_text用于定制占位文本。
• 块编辑器（Gutenberg / Block Editor）兼容：通过块编辑器添加的图片会携带署名显示。
• 模板标签 API 重构：新增基于Media_Credit类的模板标签 API，旧的函数式 API 被标记弃用；已被弃用的get_freeform_media_credit函数正式移除。
• HTML5 语义化：HTML5 模式下署名被移入<figcaption>内部（3.0.0 起则已将独立署名用<figure>包裹）。
• 运行环境要求：PHP 最低版本提升至 5.6.0。

这一版本还修复了「默认署名关闭时用户名可作为自由文本署名」的问题，说明自由文本与用户署名两条路径在实现上是解耦但可互通的。

四、从变更日志看插件的兼容性演进

变更日志中反复出现的 WordPress/TinyMCE 版本号，本身就是一份兼容性时间线，对理解插件架构演进很有价值：

此外，3.0.2 将最低 WordPress 版本提升到 4.5，4.0.3 起使用max-width替代width以改善响应式主题兼容性。安全相关的条目也有迹可循：3.1.0 提到「因自动执行 WordPress 编码规范而应用了多项安全修复与全面代码清理」，3.1.1 修复了编辑文章页直接上传媒体时的 JavaScript 错误。

五、源码级原理：WPScan 如何消费这份 CHANGELOG

5.1 动态查找器的数据来源与类过滤

WPScan 的动态查找器数据统一存放于db/dynamic_finders.yml，由 lib/wpscan/db/dynamic_finders/base.rb 中的df_file与all_df_data加载，并通过allowed_classes（%i[Comment Xpath HeaderPattern BodyPattern JavascriptVar QueryParameter ConfigParser]）限定允许的查找器类型。

而 lib/wpscan/db/dynamic_finders/plugin.rb 中的finder_configs按攻击模式筛选配置：被动（passive）检测只选用path为空的配置（如 QueryParameter），主动（aggressive）检测则选用带path的配置。对应到 Media Credit：

• QueryParameter 配置没有path字段，属于被动检测——它扫描页面中<link>/<script>的href/src，只要发现media-credit.css?ver=3.1.7这类带版本号的资源引用即可命中，无需对插件目录发额外请求；
• ChangeLog 配置带path字段（指向插件根目录的CHANGELOG.md），属于主动检测——需要先猜测插件路径并发起请求，再从返回内容中匹配版本号。

5.2 QueryParameter 的匹配与置信度

lib/wpscan/finders/dynamic_finder/version/query_parameter.rb 展示了被动识别的具体实现：默认 XPath 为//link[@href]/@href|//script[@src]/@src，版本号提取正则/(?:v|ver|version)=(?<v>\d+\.[.\d]+)/i，单次命中置信度CONFIDENCE_PER_OCCURENCE = 10。

这正好解释了 expected.yml 中confidence: 20的来源：media-credit.css?ver=3.1.7与media-credit.min.css?ver=3.1.7两处资源各贡献 10 分。而 ChangeLog 的found_by: Change Log (Aggressive Detection)与夹具目录名change_log/一一对应，说明 WPScan 的测试夹具（fixture）组织方式直接复刻了查找器命名：plugin_version/<slug>/change_log/中的文件就是 ChangeLog 查找器在测试环境中的响应样本。

5.3 从「匹配版本标题行」到版本断言

expected.yml 中 ChangeLog 条目的interesting_entries记录了具体的匹配证据：

'http://wp.lab/wp-content/plugins/media-credit/CHANGELOG.md, Match: ''## 4.0.3'''

它表明查找器在请求到 CHANGELOG 内容后，以## 4.0.3这样的版本标题行为锚点完成版本判定。夹具文档第一行## 4.0.3 (Mar. 20, 2019) ##恰好提供了这一匹配样本，验证了「变更日志最新版本行 = 插件当前版本」的推断逻辑。值得一提的是，同一夹具在 expected.yml 中被同时用于 3.1.7（被动）与 4.0.3（主动）两条断言，说明两种查找器可以基于同一插件的不同指纹（CSS 参数 vs 变更日志）给出互补结论。

六、对本仓库的实际查阅价值

对于想要深入验证这套机制的读者，可以在本仓库中按以下路径继续研读：

• 夹具本体：spec/fixtures/dynamic_finders/plugin_version/media-credit/change_log/CHANGELOG.md——既是本文核心文档，也是 ChangeLog 查找器的测试输入；
• 断言数据：spec/fixtures/dynamic_finders/expected.yml——定义期望的版本号、查找方式与置信度；
• 数据加载与过滤：lib/wpscan/db/dynamic_finders/base.rb 与 lib/wpscan/db/dynamic_finders/plugin.rb——说明被动/主动配置如何被区分与装配；
• 被动查找器实现：lib/wpscan/finders/dynamic_finder/version/query_parameter.rb——可对照理解?ver=版本提取与置信度累加规则。

七、小结

一份 2010 年至 2019 年的插件变更日志，在 WPScan 的语境下具备了双重价值：对插件维护者而言，它完整记录了 Media Credit 在署名同步、特色图、REST API、块编辑器与 HTML5 语义化上的能力演进；对安全扫描器而言，它的版本标题行成为稳定、可机器匹配的版本指纹，被 ChangeLog（主动）与 Query Parameter（被动）两类动态查找器消费，并通过plugin_version/<slug>/change_log/夹具与expected.yml断言形成闭环测试。理解这一「文档即指纹」的模式，有助于你举一反三：任何遵循## x.y.z版本行格式的 CHANGELOG 文件，都可能成为目标站点插件版本判定的低成本证据源。

• 网络安全
• 漏洞扫描
• 渗透测试
• 应用安全
• CLI