WordPress Security White Paper 系统安全白皮书

WordPress Security White Paper 系统安全白皮书

《 WordPress Security White Paper 安全白皮书》 原始为英文文档，以下内容为粗略翻译中文版本，内容质量可能欠佳，如遇遇到不通顺等问题，请协助修改，编辑此文档，以便完善文档质量，避免歧义和误导其他的阅读用户。在此免费白皮书中可了解有关 WordPress 核心软件安全性的更多信息。您也可以下载 PDF 格式的文件。

 

 

总览

本文档是对 WordPress 核心软件开发及其相关安全过程的分析和说明，以及对直接内置于软件中的固有安全性的检查。将 WordPress 评估为内容管理系统或 Web 应用程序框架的决策者应在分析和决策中使用此文档，并且供开发人员参考以熟悉软件的安全性组件和最佳实践。

本文档中的信息是该软件的最新稳定版本 WordPress 4.7 在发布时的最新信息，但是应将其视为与该软件的最新版本相关，因为向后兼容性是该软件的重点。 WordPress 开发团队。由于已将特定的安全措施和更改添加到特定版本的核心软件中，因此将予以注意。强烈建议始终运行最新的 WordPress 稳定版本，以确保获得最安全的体验。

执行摘要

WordPress 是一个动态的开源内容管理系统，用于为数百万个网站，Web 应用程序和博客提供支持。目前，它为互联网上前 1000 万个网站中的 35％以上提供动力。 WordPress 的可用性，可扩展性和成熟的开发社区使其成为各种规模的网站的流行且安全的选择。

自 2003 年成立以来，WordPress 经过不断的加固，因此其核心软件可以应对和缓解常见的安全威胁，包括 The Open Web Application Security Project（OWASP） 确定为常见安全漏洞的十大列表，本文档对此进行了讨论。 。

WordPress 安全团队与 WordPress 核心领导团队合作，并得到 WordPress 全球社区的支持，致力于在 WordPress.org 上可用于分发和安装的核心软件中识别和解决安全问题，并推荐并记录最佳安全性第三方插件和主题作者的实践。

网站开发人员和管理员应特别注意核心 API 和底层服务器配置的正确使用，这些是常见漏洞的来源，并确保所有用户使用强密码访问 WordPress 。

WordPress 概述

WordPress 是一个免费的开源内容管理系统 （CMS） 。它是世界上使用最广泛的 CMS 软件，在前 1000 万个顶级网站1 中，它所占的比重超过 35％，据估计，在使用 CMS 的所有网站中，它占有 62％的市场份额。

WordPress 已获得通用公共许可证 （GPLv2 或更高版本） 的许可，该许可证提供了四个核心自由，可以被视为 WordPress 的 「权利法案」：

  1. 出于任何目的运行程序的自由。
  2. 可以自由地研究程序的工作原理，并对其进行更改以使其按您的意愿进行。
  3. 重新分配的自由。
  4. 可以将您的修改版本的副本分发给其他人。

WordPress 核心领导团队

WordPress 项目是一个精英团队，由核心领导团队管理，并由其共同创建者和首席开发人员 Matt Mullenweg 领导。该团队负责项目的各个方面，包括核心开发，WordPress.org 和社区计划。

核心领导团队由 Matt Mullenweg，五名主要开发人员和十几个具有永久提交访问权限的核心开发人员组成。这些开发人员对技术决策拥有最终授权，并负责架构讨论和实施工作。

WordPress 有许多贡献者。其中一些是以前的或当前的提交者，而某些可能是将来的提交者。这些贡献者是 WordPress 的受信任和资深贡献者，在同行中赢得了极大的尊重。根据需要，WordPress 还具有来宾提交者，这些被授予访问权限的人可以临时访问或临时访问某些组件 （有时是特定组件） 。

核心贡献者主要指导 WordPress 开发。每个版本都有数百个开发人员向 WordPress 提供代码。这些核心贡献者是以某种方式为核心代码库做出贡献的志愿者。

WordPress 发布周期

每个 WordPress 发布周期均由一个或多个核心 WordPress 开发人员领导。从最初的范围界定会议到发布该版本，发布周期通常持续约 4 个月。

释放周期遵循以下模式2：

  • 阶段 1：规划和确保团队领导。这是在 Slack 上的 #core 聊天室中完成的。发布负责人讨论了下一版 WordPress 的功能。 WordPress 贡献者参与了该讨论。发布负责人将确定每个功能的团队负责人。
  • 阶段 2：开发工作开始。团队负责人组装团队，并致力于他们分配的功能。安排了定期的聊天，以确保开发不断向前发展。
  • 阶段 3：测试版。 Beta 已发布，并要求 Beta 测试人员开始报告错误。从此阶段开始，不再执行任何针对新增强功能或功能请求的提交。鼓励第三方插件和主题作者针对即将发生的更改测试其代码。
  • 阶段 4：发布候选。从那时起，可翻译字符串将冻结。工作仅针对回归和阻碍。
  • 阶段 5：启动。 WordPress 版本已启动，并可以在 WordPress Admin 中进行更新。

版本编号和安全性发行

WordPress 的主要版本由前两个序列决定。例如，3.5 是主要版本，3.6 、 3.7 或 4.0 也是如此。没有 「 WordPress 3」 或 「 WordPress 4」，每个主要版本均以其编号表示，例如 「 WordPress 3.9」 。

主要版本可能会添加新的用户功能和开发人员 API 。尽管通常在软件世界中，「主要」 版本意味着您可以破坏向后兼容性，但 WordPress 努力做到永不破坏向后兼容性。向后兼容是该项目最重要的理念之一，其目的是使用户和开发人员都更容易进行更新。

WordPress 的次要版本由第三个顺序决定。版本 3.5.1 和 3.4.2 3一样都是次要版本。保留了一个次要版本来修复安全漏洞并仅解决严重的错误。由于 WordPress 的新版本发布频率很高 （主要版本的目标是每 4-5 个月，而次要版本则根据需要进行），因此只需要主要版本和次要版本即可。

版本向后兼容性

WordPress 项目对向后兼容性做出了坚定承诺。这种承诺意味着主题，插件和自定义代码在 WordPress 核心软件更新时将继续起作用，从而鼓励网站所有者将其 WordPress 版本更新为最新的安全版本。

WordPress 和安全性

WordPress 安全团队

WordPress 安全团队由大约 50 位专家组成，其中包括首席开发人员和安全研究人员-大约一半是 Automattic 的员工 （WordPress.com 的制造商，这是网络上最早，最大的 WordPress 托管平台），并且在网络上开展了大量工作安全领域。该团队会与著名且值得信赖的安全研究人员和托管公司进行协商3。

WordPress 安全团队经常与其他安全团队合作以解决常见依赖项中的问题，例如解决 WordPress 3.9.2 4中 WordPress 随附的 XML-RPC API 使用的 PHP XML 分析器中的漏洞。此漏洞解决方案是 WordPress 和 Drupal 安全团队共同努力的结果。

WordPress 安全风险，流程和历史记录

WordPress 安全团队相信负责任的披露，会立即警告安全团队任何潜在的漏洞。可以通过 WordPress HackerOne 5向安全团队发出潜在的安全漏洞信号。安全团队通过专用的 Slack 通道进行相互通信，并在封闭的专用 Trac 上进行工作，以跟踪，测试和修复错误及安全问题。

每个安全报告在收到后都会得到确认，团队将努力验证漏洞并确定其严重性。如果得到确认，安全团队将计划修补此问题，该问题可以提交给即将发布的 WordPress 软件，也可以作为即时安全版本推送，具体取决于问题的严重性。

对于即时安全发布，安全团队将向 WordPress.org 新闻站点6发布公告，宣布该发布并详细说明更改。该通报中归功于对漏洞的负责任披露，以鼓励和加强将来继续进行负责任的报告。

当有新版本发布时，WordPress 软件的管理员会在其站点仪表板上看到升级通知，并且在进行手动升级后，用户将被重定向到 About WordPress 屏幕，其中详细介绍了更改。如果管理员启用了自动后台更新，则他们将在升级完成后收到一封电子邮件。

安全版本的自动后台更新

从 3.7 版开始，WordPress 为所有次要版本7（例如 3.7.1 和 3.7.2） 引入了自动后台更新。 WordPress 安全团队可以识别，修复和推出针对 WordPress 的自动化安全增强功能，而站点所有者无需在终端上做任何事情，并且该安全更新将自动安装。

当为当前稳定的 WordPress 版本推送安全更新时，核心团队还将为所有能够进行后台更新的版本推送安全更新 （自 WordPress 3.7 起），因此这些较旧但仍旧的 WordPress 版本将获得安全性增强功能。

单个站点所有者可以选择通过对其配置文件进行简单更改来删除自动后台更新，但是核心团队强烈建议保留功能，并运行 WordPress 的最新稳定版本。

2013 OWASP 十佳

开放 Web 应用程序安全性项目 （OWASP） 是致力于 Web 应用程序安全性的在线社区。 OWASP 的前 10 名列表8致力于为众多组织确定最严重的应用程序安全风险。与可利用性，可检测性和影响估计的共识估计一起，对前 10 个项目进行选择并确定优先级。

以下各节讨论 WordPress 用于增强核心软件和第三方插件和主题以抵御这些潜在风险的 API，资源和策略。

A1-注射

WordPress 中提供了一组功能和 API，可帮助开发人员确保无法注入未经授​​权的代码，并帮助他们验证和清除数据。关于如何使用这些 API 来保护，验证或清除 HTML，URL，HTTP 头中的输入和输出数据以及与数据库和文件系统进行交互时的最佳实践和文档可用9。管理员还可以进一步限制可以通过过滤器上传的文件类型。

A2-身份验证和会话管理中断

WordPress 核心软件管理用户帐户和身份验证，并在服务器端管理用户 ID，名称和密码等详细信息以及身份验证 cookie 。使用标准的加盐和扩展技术在数据库中保护密码。注销 4.0 版之后的 WordPress 版本时，现有会话将被销毁。

A3-跨站点脚本 （XSS）

WordPress 提供了一系列功能，可以帮助确保用户提供的数据安全10。受信任的用户 （即单个 WordPress 安装上的管理员和编辑者，以及仅位于 WordPress Multisite 中的网络管理员） 可以根据需要发布未过滤的 HTML 或 JavaScript，例如在帖子或页面内。默认情况下，使用 KSES 库通过 wp_kses 功能过滤不信任用户和用户提交的内容，以删除危险实体。

例如，WordPress 核心团队注意到 WordPress 2.3 发行之前，该功能 the_search_query()被大多数主题作者滥用，他们并未转义该函数的输出以用于 HTML 。在极少数情况下会稍微向后兼容，该功能的输出在 WordPress 2.3 中被更改为可预转义。

A4-不安全的直接对象参考

WordPress 通常提供直接的对象引用，例如用户帐户的唯一数字标识符或 URL 或表单字段中可用的内容。虽然这些标识符公开了直接的系统信息，但 WordPress 的丰富权限和访问控制系统可以防止未经授权的请求。

A5-安全性错误配置

大多数 WordPress 安全配置操作仅限于单个授权管理员。 WordPress 的默认设置在核心团队级别不断得到评估，并且 WordPress 核心团队提供了文档和最佳实践，以加强用于运行 WordPress 网站11 的服务器配置的安全性。

A6-敏感数据暴露

WordPress 用户帐户密码基于可移植 PHP 密码哈希框架12 进行加密和哈希处理。 WordPress 的权限系统用于控制对私人信息的访问，例如注册用户的 PII，评论者的电子邮件地址，私人发布的内容等。在 WordPress 3.7 中，核心软件中包含密码强度计，向用户设置提供了更多信息他们的密码和强度提示。 WordPress 还有一个可选的配置设置，用于要求 HTTPS 。

A7-缺少功能级别访问控制

WordPress 在执行操作之前会检查所有功能级别访问请求的适当授权和权限。未经身份验证即可访问或可视化管理 URL，菜单和页面的操作，已与身份验证系统紧密集成，以防止未经授权的用户访问。

A8-跨站请求伪造 （CSRF）

WordPress 使用称为 nonces 13 的加密令牌来验证来自授权用户的操作请求的意图，以防范潜在的 CSRF 威胁。 WordPress 提供了用于生成这些令牌的 API，以创建和验证唯一和临时令牌，并且令牌仅限于特定用户，特定操作，特定对象和特定时间段，可以将其添加到表单和所需的 URL 。此外，所有现时值在注销时均无效。

A9-使用具有已知漏洞的组件

WordPress 核心团队密切监视 WordPress 集成的少数几个包含的库和框架，以实现核心功能。过去，核心团队为多个第三方组件做出了贡献，以使其更加安全，例如更新以修复 WordPress 3.5.2 14中 TinyMCE 中的跨站点漏洞。

如果必要的话，核心团队可以决定叉子或更换关键的外部组件，比如当 SWFUpload 的库通过 Plupload 库 3.5.2 正式取代，并提供由安全小组<SWFUpload 的的安全叉15对那些在短期内继续使用 SWFUpload 的插件。

A10-未经验证的重定向和转发

WordPress 的内部访问控制和身份验证系统将防止尝试将用户定向到不需要的目的地或自动重定向。插件开发人员也可以通过 API wp_safe_redirect()16使用此功能。

进一步的安全风险和担忧

XXE（XML 外部实体） 处理攻击

在处理 XML 时，WordPress 会禁用自定义 XML 实体的加载，以防止外部实体和实体扩展攻击。除了 PHP 的核心功能之外，WordPress 并未为插件作者提供其他安全的 XML 处理 API 。

SSRF（服务器端请求伪造） 攻击

过滤由 WordPress 发出的 HTTP 请求，以防止访问回送和专用 IP 地址。此外，仅允许访问某些标准 HTTP 端口。

WordPress 插件和主题安全

默认主题

WordPress 需要启用主题以使内容在前端可见。主题开发人员团队和核心开发团队都出于安全原因对核心 WordPress（当前为 「 Twenty Twenty」） 随附的默认主题进行了严格审查和测试。

默认主题可以用作自定义主题开发的起点，站点开发人员可以创建子主题，该子主题包括一些自定义项，但在大多数功能和安全性上都依赖默认主题。如果不需要，管理员可以轻松删除默认主题。

WordPress.org 主题和插件存储库

WordPress.org 网站上列出了大约 50,000+个插件和 5,000+个主题。这些主题和插件已提交以供包含，并由志愿者手动审查，然后才能在存储库中使用。

在资源库中包含插件和主题并不能保证它们没有安全漏洞。为插件作者提供了指南，供其在提交之前参考以包含在存储库17 中，并且在 WordPress.org 网站上提供了有关如何进行 WordPress 主题开发18 的大量文档。

每个插件和主题都有能力由插件或主题所有者连续开发，并且任何后续修复或功能开发都可以上载到存储库，并在安装了该插件或主题并带有更改说明的情况下可供用户使用。向站点管理员通知需要通过其管理控制台更新的插件。

当 WordPress 安全团队发现插件漏洞时，他们将与插件作者联系并共同修复和发布该插件的安全版本。如果插件作者没有响应，或者漏洞严重，则将插件/主题从公共目录中拉出，在某些情况下，由安全团队直接修复和更新。

主题审查小组

主题审查小组由 WordPress 社区的主要成员和已建立成员领导的志愿者小组，负责审查和批准提交的主题，以将其包含在官方 WordPress 主题目录中。主题审查团队维护官方的主题审查指南19，主题单元测试数据20和主题检查插件21，并尝试与 WordPress 主题开发人员社区进行交流并就开发最佳实践进行教育。 WordPress 开发团队的核心提交者负责协调该小组的参与。

托管服务提供商在 WordPress 安全中的作用

WordPress 可以安装在多种平台上。尽管 WordPress 核心软件为操作安全的 Web 应用程序提供了许多规定，这些规定已在本文档中介绍，但操作系统和托管该软件的底层 Web 服务器的配置对于确保 WordPress 应用程序的安全同样重要。

关于 WordPress.com 和 WordPress 安全性的注意事项

WordPress.com 是世界上最大的 WordPress 安装，并由 Automattic，Inc. 拥有和管理，该公司由 WordPress 项目共同创建者 Matt Mullenweg 创立。 WordPress.com 在核心 WordPress 软件上运行，并具有自己的安全性流程，风险和解决方案22。本文档涉及有关自托管的，可下载的开源 WordPress 软件的安全性，该软件可从 WordPress.org 获得，并可在世界上的任何服务器上安装。

附录

核心 WordPress API

WordPress 核心应用程序编程接口 （API） 由几个单独的 API 23 组成，每个 API 涵盖了一组给定功能所涉及和使用的功能。这些共同构成了项目界面，该界面允许插件和主题安全可靠地与 WordPress 核心功能进行交互，更改和扩展。

虽然每个 WordPress API 提供了与 WordPress 核心软件进行交互和扩展的最佳实践和标准化方法，但以下 WordPress API 与加强和加强 WordPress 安全性最相关：

数据库 API

WordPress 0.71 中添加 的 Database API 24提供了正确的方法来访问作为存储在数据库层中的命名值的数据。

文件系统 API

WordPress 2.6 26 中添加 的 Filesystem API 25最初是为 WordPress 自身的自动更新功能创建的。 Filesystem API 提取了在各种主机类型上安全地完成将本地文件读写到文件系统所需的功能。

它通过 WP_Filesystem_Base 该类以及几个子类来实现此目的，具体取决于各个主机的支持情况，这些子类实现了连接到本地文件系统的不同方式。任何需要在本地写入文件的主题或插件都应使用 WP_Filesystem 系列类来完成。

HTTP API

HTTP API 27（在 WordPress 2.7 28 中添加并在 WordPress 2.8 中进一步扩展） 使 WordPress 的 HTTP 请求标准化。该 API 处理 Cookie，gzip 编码和解码，块解码 （如果使用 HTTP 1.1） 以及其他各种 HTTP 协议实现。 API 标准化请求，在发送之前测试每种方法，并根据您的服务器配置，使用适当的方法发出请求。

权限和当前用户 API

权限和当前用户 API 29是一组功能，将有助于验证当前用户的权限和执行所请求的任何任务或操作的权限，并可以进一步防止未经授权的用户访问或执行超出其允许功能的功能。

白皮书内容许可

本文档中的文本 （不包括 WordPress 徽标或商标） 经 CC0 1.0 Universal（CC0 1.0）Public Domain Dedication 许可。您可以复制，修改，分发和执行作品，甚至出于商业目的，而无需征求许可。

特别感谢 Drupal 的安全性白皮书，该白皮书提供了一些启发。

附加阅读

由 Sara Rosso 撰写

来自 Barry Abrahamson，Michael Adams，Jon Cave，HelenHou-Sandí，Dion Hulse，Mo Jangda，Paul Maiorana 的贡献

版本 1.0 2015 年 3 月

脚注

子项：WordPress 公益非盈利网站指南