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