當出現安全問題時，是否應該從 WordPress 存儲庫中暫停維護的插件？

2020 年 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&current-step=access

這是允許您指定誰可以查看日誌的嚮導步驟。 在 HTML 頁面的源代碼中搜索“_wpnonce”隨機數，將其複制並插入到以下 curl 命令中：

$ curl 'http://example.com/wp-admin/admin-post.php?page=wsal-setup&current-step=access' -d '_wpnonce=INSERT-NONCE-HERE&wsal-access=yes&editors%5B%5D=訂閱者&save_step=下一步'

以訂閱者身份登錄後，您將可以完全訪問插件設置。

為什麼我們認為這個案子處理不當？

在我們收到的電子郵件中，有以下內容：

我們不會輕易關閉插件，當涉及到安全問題時，我們會嘗試在用戶數量和開發人員歷史記錄與報告的嚴重性和潛在損害之間取得平衡。

但是，我認為我們的插件退出得太早了。 迄今為止;

1. 當我們過去遇到問題時，我們總是在幾個小時內解決它們。 這次我們也做了同樣的事情。
2. 當插件審查團隊取得聯繫時，我們總是按時回复。
3. 安全問題只影響了我們的插件（低嚴重性），這是一個邊緣案例。
4. 無法自動利用安全問題。
5. 攻擊者唯一可以做的破壞是更改插件設置、讀取活動日誌或清除它們。

其他開發人員如何看待這種情況？

我們中的大多數人已經在社交媒體上閱讀過關於類似問題的文章、推文或消息。 但是，我想親自了解其他人，尤其是開發人員，對此有何看法。 我認為這很重要，因為可能有些東西我沒有看到。

首先，我向發現問題的人發送了一封電子郵件，感謝他負責任的披露。 他的回應是：

“很高興看到您迅速解決了插件中的問題。 順便說一句，我注意到 wordpress.org 的人關閉了它幾天，這有點苛刻，並不是真正需要的。”- Jerome Bruandet。

我還在 Facebook 小組 Selling WordPress Products 上做了一個小調查。 雖然這個小組很小，但它的大多數成員都是插件和主題開發人員。 從民意調查中我們可以看到，開發人員一致同意，如果出現低到中等嚴重性問題，應聯繫開發人員並給予他們提供修復而不是撤回插件的機會：

如何改進這些程序？

據我所知，當有人報告插件中的安全問題時，沒有記錄在案的程序。 如果是這種情況，像下面這樣的程序可能會幫助開發人員，也會讓更少的人面臨風險。

在關閉插件之前聯繫開發人員並商定行動計劃

插件審核團隊可以在關閉插件之前嘗試聯繫開發人員並確認漏洞。 開發人員應回復行動計劃，包括修復的合理日期。

如果需要，插件審核團隊可以設置截止日期。 例如，開發人員應該有 12 到 24 小時的時間來解決問題。 但是，在某些情況下，他們可能需要更多時間，具體取決於他們所在的時區等。如果開發人員未能響應，則應從存儲庫中撤回該插件。

確定安全問題的嚴重性和類型

這可能是有爭議的。 但是，具有一點安全經驗的人可以很容易地判斷報告的安全問題是否可以被自動利用，是否是邊緣案例，以及報告的概念證明 (POC) 的影響是什麼。

檢查開發人員是否遵守行動計劃

應該進行某種檢查，以確認開發人員按時提交修復並堅持行動計劃中包含的任何其他任務。

從存儲庫中撤回維護的插件無濟於事

在維護插件的情況下，從存儲庫中撤回它們弊大於利。 例如;

1. 您公開該插件有問題，很可能是安全問題。 這引發了很多警報，並使插件成為焦點。 這也像邀請攻擊者，告訴他們插件中的某些內容可能是可利用的。
2. 它暴露了當前的插件用戶群，因為突然之間，他們的網站成為了目標。 大多數用戶不知道他們應該做什麼，特別是如果插件的功能是他們網站和業務的核心。
3. 您增加了延遲修復的機會。 這通常是由於缺乏溝通，或由於節假日和周末造成的。

有人可能會爭辯說，通過從存儲庫中撤回插件，您可以阻止感染傳播。 但是，如果安全問題的嚴重性較低，則無法自動利用，並且披露有責任，不涉及風險，或者風險極低。

免責聲明：這不是攻擊

我想指出，這不是針對 WordPress 插件審查團隊或參與這些流程的任何人的攻擊。 老實說，我尊重他們的工作，我知道他們所做的一切都是真誠的。 但是，就像在其他所有系統和流程中一樣，肯定有需要改進的地方。

許多人可能會告訴我，如果我想要改變，我應該自願而不是寫這篇文章。

我已經嘗試加入很長一段時間了； 我已經與不同 WordCamps 的幾個人進行了交談以參與其中，並且我還一直在監視 Make WordPress 插件頁面以徵集志願者。 然而，在過去的幾年裡，他們沒有任何職位空缺。 當他們需要幫助時，他們只能通過邀請來添加新成員。