当出现安全问题时，是否应该从 WordPress 存储库中暂停维护的插件？
已发表: 2020-03-122020 年 2 月 27 日，晚上 9:34（欧洲中部时间），我们收到了一封电子邮件，通知我们我们的插件 WP 活动日志“由于漏洞而暂时从 WordPress.org 插件目录中撤出”。
我们于 2020 年 2 月 28 日星期五下午 4:08 提交了修复程序。 我们只用了 16.5 小时就发布了修复程序。 如果这发生在我们的正常工作时间（我们位于欧洲），我们会更早地解决这个问题，因为我们有一个非常好的支持响应时间（参考）。
我们的插件已于 2020 年 3 月 2 日星期一下午 1 点恢复。 那是我们提交修复后的 69 小时。 需要注意的是，由于周末，团队花了很长时间才恢复插件。
我为什么要写这个？
我想指出，我确实认为存在安全问题的非维护插件应该从 WordPress 存储库中暂停。 此外，我非常尊重插件审查团队的志愿者所做的工作，我也对报告的安全问题承担全部责任。
但是，我确实相信在维护的插件中报告的安全问题可能会得到更好的处理。 由于目前的处理方式，该插件的声誉受到了很大的负面影响，其用户和他们的网站都处于危险之中。 因此，在这篇文章的最后，我强调了一些可能有帮助的改进，我认为应该考虑它们。 这个想法是始终让更少的用户面临风险，并减少对插件和开发人员的影响。
在这篇文章中，我还记录了发生的所有细节，并解释了我们插件中报告的低严重性边缘案例漏洞。
报告 WordPress 插件安全问题的程序是什么？
来自插件手册中的官方指南：
在您向我们报告插件之前，应先尝试直接联系开发人员（尽管我们知道这可能很困难 - 首先检查插件的源代码，许多开发人员列出了他们的电子邮件）。 如果您无法私下联系他们，请直接与我们联系，我们将提供帮助。
在我们的案例中发生了什么？
我们在插件中非常清楚谁开发了插件。 只需查看存储库上的插件页面，您就会明白！ 我们也很容易与我们联系。
但是，在插件暂时从插件存储库中撤出之前，没有人向我们报告安全问题。 所以有人向 WordPress 插件审查团队报告了这个问题，他们在没有任何事先通知的情况下暂时从存储库中撤回了我们的插件。
在我们深入探讨原因和原因，以及什么是好的、坏的以及可以改进的地方之前，让我们先看看插件漏洞并简要说明我们是谁。
插件漏洞是什么？
我们在 WP 活动日志中有一个安装向导来帮助用户配置插件。 向导中的一项设置允许您允许非管理员用户阅读活动日志。
但是，我们犯了一个错误； 我们没有检查运行向导的用户是否经过身份验证。 因此未经身份验证的用户可以运行向导并允许其他用户或角色访问插件的设置。 但是，这是一个边缘情况低严重性问题。
为什么这是一个低严重性边缘案例安全问题？
攻击者只有在以下情况下才能利用它：
- 安装程序从未完成安装向导，
- 攻击者已经拥有用户/可以访问网站上的用户，
- 攻击者只能访问插件的设置和活动日志。
通过利用此安全问题，攻击者无法访问 WordPress 网站上的其他权限。 因此，此漏洞不会对网站的行为和功能本身产生任何负面影响。
概念证明
POC 非常简单。 以未经身份验证的用户身份访问此页面：
http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access
这是允许您指定谁可以查看日志的向导步骤。 在 HTML 页面的源代码中搜索“_wpnonce”随机数，将其复制并插入到以下 curl 命令中：
$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup¤t-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D=订阅者&save_step=下一步'
以订阅者身份登录后，您将可以完全访问插件设置。
为什么我们认为这个案子处理不当？
在我们收到的电子邮件中，有以下内容：
我们不会轻易关闭插件，当涉及到安全问题时，我们会尝试在用户数量和开发人员历史记录与报告的严重性和潜在损害之间取得平衡。
但是，我认为我们的插件退出得太早了。 迄今为止;
- 当我们过去遇到问题时，我们总是在几个小时内解决它们。 这次我们也做了同样的事情。
- 当插件审查团队取得联系时，我们总是按时回复。
- 安全问题只影响了我们的插件（低严重性），这是一个边缘案例。
- 无法自动利用安全问题。
- 攻击者唯一可以做的破坏是更改插件设置、读取活动日志或清除它们。
其他开发人员如何看待这种情况？
我们中的大多数人已经在社交媒体上阅读过关于类似问题的文章、推文或消息。 但是，我想亲自了解其他人，尤其是开发人员，对此有何看法。 我认为这很重要，因为可能有些东西我没有看到。
首先，我向发现问题的人发送了一封电子邮件，感谢他负责任的披露。 他的回应是：
“很高兴看到您迅速解决了插件中的问题。 顺便说一句，我注意到 wordpress.org 的人关闭了它几天，这有点苛刻，并不是真正需要的。”- Jerome Bruandet。
我还在 Facebook 小组 Selling WordPress Products 上做了一个小调查。 虽然这个小组很小，但它的大多数成员都是插件和主题开发人员。 从民意调查中我们可以看到，开发人员一致同意，如果出现低到中等严重性问题，应联系开发人员并给予他们提供修复而不是撤回插件的机会：
如何改进这些程序？
据我所知，当有人报告插件中的安全问题时，没有记录在案的程序。 如果是这种情况，像下面这样的程序可能会帮助开发人员，也会让更少的人面临风险。
在关闭插件之前联系开发人员并商定行动计划
插件审核团队可以在关闭插件之前尝试联系开发人员并确认漏洞。 开发人员应回复行动计划，包括修复的合理日期。
如果需要，插件审核团队可以设置截止日期。 例如，开发人员应该有 12 到 24 小时的时间来解决问题。 但是，在某些情况下，他们可能需要更多时间，具体取决于他们所在的时区等。如果开发人员未能响应，则应从存储库中撤回该插件。
确定安全问题的严重性和类型
这可能是有争议的。 但是，具有一点安全经验的人可以很容易地判断报告的安全问题是否可以被自动利用，是否是边缘案例，以及报告的概念证明 (POC) 的影响是什么。
检查开发人员是否遵守行动计划
应该进行某种检查，以确认开发人员按时提交修复并坚持行动计划中包含的任何其他任务。
从存储库中撤回维护的插件无济于事
在维护插件的情况下，从存储库中撤回它们弊大于利。 例如;
- 您公开该插件有问题，很可能是安全问题。 这引发了很多警报，并使插件成为焦点。 这也像邀请攻击者，告诉他们插件中的某些内容可能是可利用的。
- 它暴露了当前的插件用户群，因为突然之间，他们的网站成为了目标。 大多数用户不知道他们应该做什么，特别是如果插件的功能是他们网站和业务的核心。
- 您增加了延迟修复的机会。 这通常是由于缺乏沟通，或由于节假日和周末造成的。
有人可能会争辩说，通过从存储库中撤回插件，您可以阻止感染传播。 但是，如果安全问题的严重性较低，则无法自动利用，并且披露有责任，不涉及风险，或者风险极低。
免责声明：这不是攻击
我想指出，这不是针对 WordPress 插件审查团队或参与这些流程的任何人的攻击。 老实说，我尊重他们的工作，我知道他们所做的一切都是真诚的。 但是，就像在其他所有系统和流程中一样，肯定有需要改进的地方。
许多人可能会告诉我，如果我想要改变，我应该自愿而不是写这篇文章。
我已经尝试加入很长一段时间了； 我已经与不同 WordCamps 的几个人进行了交谈以参与其中，并且我还一直在监视 Make WordPress 插件页面以征集志愿者。 然而，在过去的几年里，他们没有任何职位空缺。 当他们需要帮助时，他们只能通过邀请来添加新成员。