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 公益非盈利網站指南