Logo

安全與隱私白皮書（概述）第11章

第11章：漏洞揭露與安全性更新

FileBolt 鼓勵負責任的揭露並透過可預測的補救和溝通機制建立信任。 同時，安全功能必須是可進化的：包括 Web 安全性原則、伺服器端身份驗證機制和端對端加密/協定實作（例如， cryptoVersion 升級）。本章概述了公共聯繫管道、處理工作流程、修復發布和公告原則，並解釋了版本化演變和棄用策略。

11.0 總結

  • MUST：提供公共漏洞提交管道（例如 security.txt 和支援電子郵件）。
  • SHOULD：提供加密提交機制（例如，PGP 金鑰）以安全地提交詳細資訊。
  • SHOULD：定義明確的回應和補救節奏（SLA/目標時間表），並在必要時透過狀態頁面進行溝通。
  • MUST：將可能影響零知識承諾的漏洞（XSS、供應鏈注入、日誌片段洩漏）視為最高優先順序。
  • MUST：實現版本化進化（cryptoVersion）並定義相容性、遷移和棄用策略。

11.1 漏洞提交管道及聯絡方式

11.1.1 公共入口點

  • MUST：提供漏洞提交管道、有效期限、政策鏈接 /.well-known/security.txt.
  • MUST：提供可聯絡的安全聯絡人電子郵件（例如， support@filebolt.net 或專用 security@filebolt.net).
  • SHOULD：提供有關的簡要說明和提交指南 安全與隱私 page.

11.1.2 加密提交和敏感資訊處理

  • SHOULD：提供 PGP 公鑰（或等效金鑰），以便研究人員安全地提交複製詳細資訊。
  • MUST：在內部強制執行漏洞詳細資訊的最低權限可見性，僅向需要修復的人員揭露。
  • MUST：禁止研究人員在報告中包含使用者明文、CEK、URL 片段或可匯出的關鍵資料；如果無意中包含在內，團隊必須將其視為敏感事件並限制傳播。

11.2 回應時間表和溝通原則

時間表取決於團隊規模和複雜性，但專案應該提供可預測的目標節奏，並在錯過目標時及時溝通。 建議目標（根據實際情況調整，發佈在/security或security.txt中）：

  • 第一反應：例如，在 48 小時內確認收貨並分配追蹤 ID。
  • 初步評估：例如，7天內完成嚴重程度分級和影響範圍評估。
  • 修復發布：根據嚴重程度進行進展； P0/P1 優先考慮快速修復和發布。

SHOULD：在處理過程中保持必要的溝通（例如，複製/不複製、需要更多資訊、估計修復視窗）並避免公開披露可利用的細節。

11.3 揭露流程

  1. Receipt：記錄報告資訊、重現步驟、影響、研究者聯絡方式；指定所有者和追蹤。
  2. Verification：在隔離環境中繁殖；評估影響範圍、可利用性和受影響的組件（前端/後端/邊緣/儲存）。
  3. Remediation：實作補丁，新增測試/回歸案例，必要時新增保護規則（WAF/速率限制/策略收緊）。
  4. Release：金絲雀發布並監控關鍵指標；確認無回歸或新風險後全面發布。
  5. Announcement：公開解釋影響、修復內容和所需的使用者操作（如果有），而不擴大攻擊面。

對於嚴重漏洞或高用戶影響事件， SHOULD 透過發布事件更新或事後分析 /status 與第 10 章 IR 流程保持一致。

11.4 影響零知識邊界的漏洞

零知識承諾的核心是：伺服器無法存取CEK，下載/解密環境盡可能隔離，無需第三方腳本。 因此，以下類別必須被視為最高優先事項：

  • XSS/注入：能夠在下載/解密頁面上執行任意腳本，讀取片段或記憶體金鑰材料。
  • 供應鏈注入：依賴中毒、建構工件替換、CDN/Edge 注入導致腳本篡改。
  • 記錄/監控洩漏：URL 片段、CEK、令牌或純文字意外記錄且可存取。
  • 資源載入策略不正確：下載/解密頁面匯入第三方腳本，CSP放鬆擴充執行面。

處置應包括：立即遏制（離線風險代碼/收緊政策/禁令向量）、快速修復發布、回顧性影響分析、 並在公告中明確聲明「是否有可能洩漏關鍵資料或明文」。

11.5 安全性更新與回歸驗證

  • MUST：建立安全相關變更的迴歸案例（驗證、存取控制、CSP、日誌過濾、加密流程）。
  • SHOULD：對關鍵頁面（下載/解密）執行自動檢查，以確保沒有第三方腳本和標頭策略符合預期。
  • SHOULD：修正發布後執行外部可驗證項目重新測試（例如 TLS/安全標頭掃描）。
  • SHOULD：清楚地記錄文件中修復（例如舊連結/舊清單）引入的兼容性變更。

與第12章一致：第三方掃描驗證一些Web基線，但不能直接證明完整的零知識/E2EE實作細節； 因此，回歸驗證應涵蓋協議實施和可見基線。

11.6 協定和密碼版本控制（cryptoVersion）

FileBolt 的加密和協定實作必須支援版本控制，以方便演算法升級、修復實作缺陷並引入更強的隔離。 建議使用顯式欄位（例如， cryptoVersion）綁定在清單/元資料中。

  • 明確版本：每份轉讓/清單必須聲明其 cryptoVersion 確定演算法、參數和編碼規則。
  • 無隱式推理：客戶端必須根據顯式清單欄位決定解析和解密邏輯，而不是猜測或回退啟發式。
  • 失敗關閉：遇到未知版本或不一致參數時必須失敗關閉，切勿降級到不安全模式。

11.7 相容性、遷移和棄用

11.7.1 向後相容性

  • SHOULD：支援過渡期間讀取舊傳輸版本，盡量減少對使用者歷史連結的影響。
  • MUST：公開聲明舊版的安全邊界、限制和棄用計畫。

11.7.2 遷移（保持零知識）

  • SHOULD：如果需要從舊版本遷移到新版本，請提供「重新上傳/重新加密」用戶端路徑。
  • MUST：遷移過程中保持零知識：客戶端重新加密，伺服器無法存取CEK或明文。

11.7.3 棄用和 EOL

  • MUST：為被認為不再安全的版本提供明確的生命週期終止時間表。
  • SHOULD：提示使用者在UI/Docs中重新上傳，並提供足夠的遷移視窗。
  • MUST：EOL 後，遇到已棄用版本的用戶端應明確提示，且不得嘗試解密。

11.8 相關聲明 ID（保留）

本章涵蓋「漏洞揭露管道、工作流程、版本控制和棄用」。 相應的索賠 ID 將添加到 附錄：索賠 ID 主列表 作為唯一的權威來源。