johnbillion/rave-wordpress

[](https://github.com/johnbillion/rave-wordpress/actions/workflows/rave.yml) # WordPress 版 RAVE RAVE for WordPress 是一个供应链安全工具，它从源代码复现 WordPress 的构建，并将它们与已发布的 WordPress 包进行比较，以验证包未被篡改。来自 wordpress.org 的包以及来自 GitHub 和各第三方的包都会进行测试。 GitHub Actions 上运行着一个 CI 系统，它从官方源复现构建，获取在多个官方和非官方位置发布的包，并将它们相互比较以验证其完整性并识别任何异常。对于通过验证的包，会生成一份 in-toto 发布证明。 RAVE 代表 Reproduce And Verify（复现并验证）。 ## 测试内容？ ### 源代码 * ✅ `develop.svn.wordpress.org` * ✅ `develop.git.wordpress.org` * ✅ `github.com/wordpress/wordpress-develop` * ✅ `core.trac.wordpress.org` ### 官方包 * ✅ `wordpress.org/latest.zip` * ✅ `wordpress.org/wordpress-{tag}.zip` * ✅ `downloads.wordpress.org/release/wordpress-{tag}.zip` * ✅ `downloads.w.org/release/wordpress-{tag}.zip` * ✅ `github.com/wordpress/wordpress` * ✅ `build.trac.wordpress.org` ### 官方构建 * ✅ `core.git.wordpress.org` * ✅ `core.svn.wordpress.org` ### 非官方包 * ✅ 来自 WPEngine 的 `core-updates.wpengine.com` * ✅ 来自 AspireCloud 的 `api.aspirecloud.net` * ✅ FAIR 提供的 Bundle 包 * ✅ Packagist 上的 `roots/wordpress-full` * ✅ Packagist 上的 `johnpbloch/wordpress` ### 其他验证 * ✅ 针对 wordpress.org 包验证 wordpress.org 上发布的 MD5 和 SHA-1 哈希 * ✅ 针对 wordpress.org 包验证 `api.wordpress.org/core/checksums` 返回的校验和 * ✅ 针对 wordpress.org 包验证 `api.wordpress.org/core/version-check` 返回的更新 URL * ✅ 针对 wordpress.org 包验证 `api.wordpress.org/core/stable-check` 返回的版本是否符合预期 * ✅ 验证分发者是否提供了比最新官方版本更新的版本 ## 测试何时运行？ GitHub Actions 工作流每小时运行一次。它验证运行时可用的最新 WordPress 版本。 ## RAVE 何时开始验证 WordPress 版本？ RAVE 项目是在 2024 年 WordCamp US 会议之后启动的。它在发布时验证的第一个版本是 6.7。 ## 为什么要测试官方包？ 官方 WordPress 包有多种机会被篡改，从而使其与源代码仓库中的实际源代码不同。这可能源于对构建服务器、wordpress.org 或 downloads.wordpress.org 的攻击，来自外部黑客，来自控制 wordpress.org CDN 的人，来自心怀不满的 meta 或系统团队成员，来自任何获得此类团队成员账户或凭证访问权限的人，或来自项目负责人。 ### 现实案例 * [2007 年，一名攻击者获得了 wordpress.org 服务器的访问权限，并在 WordPress 2.1.1 包中添加了后门](https://wordpress.org/news/2007/03/upgrade-212/)。RAVE 本可以通过以下方式成功检测到这一点： * 检测到 wordpress.org 提供的 2.1.1 包与从源代码复现的包不匹配 * 在失败的工作流差异中立即使后门代码可见 * [2016 年，Wordfence 识别出了 api.wordpress.org 上 webhook 机制中的一个漏洞](https://www.wordfence.com/blog/2016/11/hacking-27-web-via-wordpress-auto-update/)，并演示了攻击者理论上可以在 api.wordpress.org 服务器上执行 shell 命令。如果攻击者利用此漏洞修改现有版本或创建新版本，RAVE 本可以通过以下方式成功检测到这一点： * 识别出源代码仓库中不存在的新版本 * 识别出与从源代码仓库构建的代码不匹配且与别处发布的版本不匹配的已修改包 * 识别出在更新 API 响应中从意外主机名或 URL 提供更新的任何企图 * 识别出已发布的 SHA-1 和 MD5 哈希、已发布的校验和与更新 API 返回的提供内容之间的任何差异 ## 为什么要测试非官方包？ 非官方 WordPress 包有多种机会被篡改，从而使其与官方包不同。这可能源于对分发包的服务器的攻击，来自外部黑客，来自控制打包过程的人，或来自任何获得涉及打包或分发的人员或流程的账户或凭证访问权限的人。 ## 如何实现？ 通过比较分发包在各个位置的内容与构建源代码的输出，可以识别异常。这减少了将恶意或不需要的代码引入 WordPress 包的机会，除非这些代码也存在于源代码仓库、流水线仓库和其他分发包中。 如果此仓库中的某个 GitHub Actions 工作流失败，应进行调查以查看失败是否由代码分歧引起。包之间的任何差异都会立即在工作流运行输出中可见。 ## 未测试什么？ 这种方法： * **不**检测被提交到 Subversion 源代码仓库并随后进入发布包的恶意或不需要的代码。 * **不**检测根据客户端请求的 IP 地址或 User-Agent 等参数导致包内容发生变化的针对性攻击。 * **不**处理构建来源验证或软件签名。 ## 可复现的 WordPress 引用 [reproducible-builds.org](https://reproducible-builds.org/) 的话： [构建和打包 WordPress 的过程](https://build.trac.wordpress.org/timeline) 就构建代码而言是可复现的，尽管我认为 zip 文件的生成在不同次调用之间不会产生稳定的哈希值。不幸的是，该过程本身不是开源的。该过程与源代码中的 `npm run build` 过程不同，因为它进行了一些添加（例如 Akismet 插件）和一些排除（较旧的默认主题）。此仓库执行的验证考虑到了这一点。 ## 可验证的 WordPress wordpress.org 网站[提供其 WordPress 包文件的 MD5 和 SHA-1 哈希](https://wordpress.org/download/releases/)。这不足以单独验证一个包，因为哈希仅代表 zip 或 tar 文件，如果 wordpress.org 上的包被更改，那么其发布的 MD5 和 SHA-1 哈希也可能被更改。 WordPress 开源项目不使用包签名来验证包。[请参阅工单 #39309 关于此主题的讨论](https://core.trac.wordpress.org/ticket/39309)。 因此，创建此库是为了提供一种手段来验证发布包的内容与从官方源代码仓库构建的代码是否匹配。 ## 证明 RAVE 在复现并验证给定的 WordPress 包后会生成一个 [in-toto 发布证明](https://github.com/in-toto/attestation/blob/main/spec/predicates/release.md)。如果您信任 RAVE，则可以使用其证明来验证您下载的 WordPress 包，例如在命令行中使用 `gh`： ``` wget https://wordpress.org/wordpress-6.8.2.zip gh attestation verify wordpress-6.8.2.zip --repo johnbillion/rave-wordpress --predicate-type "https://in-toto.io/attestation/release/v0.1" ``` ``` wget https://api.aspirecloud.net/download/wordpress-6.8.2.zip gh attestation verify wordpress-6.8.2.zip --repo johnbillion/rave-wordpress --predicate-type "https://in-toto.io/attestation/release/v0.1" ``` 如果您想下载并检查证明的元数据（JSON 格式）： ``` file="wordpress-6.8.2.zip" hash=$(shasum -a 256 "$file" | cut -d" " -f1) gh attestation download "$file" --repo johnbillion/rave-wordpress jq -r '.dsseEnvelope.payload' "sha256:${hash}.jsonl" | base64 -d | jq . ``` ## 这是否有助于 WordPress 遵循 SLSA？ 不。[SLSA](https://slsa.dev/) 是一个安全框架，通过在其构建和发布过程中生成可验证的构建来源证明来提高软件包的供应链韧性。RAVE _独立复现_ WordPress 的构建，但不是发布过程本身的一部分，因此由 RAVE 生成 SLSA 构建来源证明是不合适的。 ## 校验和 完整 WordPress 包中文件的校验和可以在[校验和目录中](https://github.com/johnbillion/rave-wordpress/tree/trunk/checksums)找到。这些是_作为便利_提供的，仅应用于非对抗性的文件完整性检查，因为它们使用加密强度较弱的 MD5 算法，并且是直接从 api.wordpress.org 获取的。 要使用此仓库中提供的校验和验证 WordPress 安装的完整性： ``` wget https://raw.githubusercontent.com/johnbillion/rave-wordpress/trunk/checksums/6.8.2.md5 md5sum --check 6.8.2.md5 ``` ## 许可证 MIT

标签：CMS安全, Cutter, DevSecOps, GitHub Actions, in-toto, JavaScript, SLSA, WordPress, 上游代理, 可复现构建, 哈希验证, 安全合规, 完整性校验, 文档安全, 暗色界面, 构建复现, 网络代理, 网络安全研究, 自动笔记, 软件开发工具包, 软件溯源, 防篡改