私有資料、刪除的內容可以永久訪問，GitHub官方：故意設計的

最近，一個訊息震驚開源社群：在 GitHub 上刪除的內容、私人儲存庫的資料都是可以永久存取的，而且這是官方故意設計的。

開源安全軟體公司 Truffle Security 在一篇部落格中詳細描述了這個問題。

Truffle Security 引入了一個新術語：CFOR（Cross Fork Object Reference）：當一個儲存庫fork 可以存取另一個fork 中的敏感資料（包括來自私有和已刪除fork 的資料）時，就會存取另一個fork 中的敏感資料（包括來自私有和已刪除fork 的資料）時，就會存取另一個fork出現CFOR 漏洞。

與不安全的直接物件引用類似，在 CFOR 中，使用者提供提交（commit）雜湊值就可以直接存取提交數據，否則這些數據是不可見的。

以下是 Truffle Security 部落格原文內容。

存取已刪除fork 儲存庫的資料

想像以下工作流程：

• 在GitHub 上fork 一個公用儲存庫；

• 在GitHub 上fork 一個公用儲存庫；

• 你刪除你的fork 儲存庫。

那麼，你提交給 fork 的程式碼應該是不能存取了對吧，因為你把 fork 儲存庫刪除了。然而它卻永久可以訪問，不受你控制。 

如下影片所示，fork 一個儲存庫，向其中提交數據，再刪除 fork 儲存庫，那麼可以透過原始儲存庫存取「已刪除」的提交資料。

這種情況普遍存在。 Truffle Security 調查了一家大型 AI 公司 3 個經常被 fork 的公共儲存庫，並從已刪除的 fork 儲存庫中輕鬆找到了 40 個有效的 API 金鑰。

存取已刪除儲存庫的資料

考慮如下工作流程：

• 你在Gitf你在他們fork 後提交數據，並且他們從不將其fork 存儲庫與你的更新同步；

• 你刪除整個存儲庫。

那麼，用戶 fork 你的儲存庫後你提交的程式碼仍然可以存取。

• GitHub 將儲存庫和 fork 儲存庫儲存在儲存庫網路中，原始「上游」儲存庫充當根節點。當已 fork 的公共「上游」儲存庫被「刪除」時，GitHub 會將根節點角色重新指派給下游 fork 儲存庫之一。但是，來自「上游」儲存庫的所有提交仍然存在，並且可以透過任何 fork 儲存庫存取。

這種情況不是個例，上週就發生了這樣一件事情：

Truffle Security 向一家大型科技公司提交了一個P1 漏洞，顯示他們意外地提交了一名員工GitHub帳戶的金鑰，而該帳戶對整個GitHub 機構擁有重要存取權限。該公司立即刪除了儲存庫，但由於該儲存庫已被 fork，因此仍然可以透過 fork 儲存庫存取包含敏感資料的提交，儘管 fork 儲存庫從未與原始「上游」儲存庫同步。

也就是說，只要儲存庫有至少一個 fork 儲存庫，那麼提交到公共儲存庫的任何程式碼都可以永久存取。 存取私有儲存庫資料

考慮以下工作流程：

你建立一個最終將公開的私人儲存庫；

你建立一個最終將公開的私人儲存庫；

• 不打算公開的特徵提交額外的程式碼；

• 你將你的「上游」儲存庫公開，並將你的fork 儲存庫保持私有。

• 那麼，私有特徵和相關代碼則可供公眾查看。從你創建工具的內部 fork 儲存庫到開源該工具之間提交的任何程式碼，這些提交都可以透過公共儲存庫存取。

  在你將「上游」儲存庫公開後，對你的私有 fork 儲存庫所做的任何提交都是不可見的。這是因為更改私有「上游」儲存庫的可見性會導致兩個儲存庫網路：一個用於私有版本，一個用於公開版本。

  

  不幸的是，該工作流程是使用者和機構開發開源軟體時最常用的方法之一。因此，機密資料可能會無意中暴露在 GitHub 公共儲存庫上。

  如何存取資料？

  GitHub 儲存庫網路中的破壞性操作（如上述 3 個場景）會從標準 GitHub UI 和正常 git 操作中刪除提交資料的引用。但是，這些數據仍然存在並且可以存取（commit hash）。這是 CFOR 和 IDOR 漏洞之間的關聯。

  

  commit hash 可以透過 GitHub 的 UI 進行暴力破解，特別是因為 git 協定允許在引用提交時使用短 SHA-1 值。短 SHA-1 值是避免與另一個 commit hash 發生衝突所需的最小字元數，絕對最小值為 4。所有 4 個字元 SHA-1 值的金鑰空間為 65536 (16^4)。暴力破解所有可能的值可以相對容易地實現。

  

  

  有趣的是，GitHub 公開了一個公共事件 API 端點。你也可以在由第三方管理的事件存檔中查詢 commit hash，並將過去十年的所有 GitHub 事件保存在 GitHub 之外，即使在儲存庫被刪除之後也是如此。

  GitHub 的規定

  Truffle Security 透過 GitHub 的 VDP 計畫將其發現提交給了 GitHub 官方。 GitHub 回應道：「這是故意設計的」，並附上了說明文件。

  

  

  

  說明文件：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-app-app forks-when-a-repository-is-deleted-or-changes-visibility

  Truffle Security 讚賞GitHub 對其架構保持透明，但Truffle Security 認為：普通用戶將私有和公共儲存庫的分離視為安全邊界，並且認為公共用戶無法存取私有儲存庫中的任何資料。不幸的是，如上所述，情況並不總是如此。

  Truffle Security 得出的結論是：只要一個 fork 儲存庫存在，對該儲存庫網路的任何提交（即「上游」儲存庫或「下游」fork 儲存庫上的提交）都將永久存在。

  Truffle Security 也提出一種觀點：安全修復公共 GitHub 儲存庫上洩漏金鑰的唯一方法是透過金鑰輪換。

  GitHub 的儲存庫架構存在這些設計缺陷。不幸的是，絕大多數 GitHub 使用者永遠不會理解儲存庫網路的實際運作原理，並且會因此而降低安全性。

  ^{原文連結：https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github}

以上是私有資料、刪除的內容可以永久訪問，GitHub官方：故意設計的的詳細內容。更多資訊請關注PHP中文網其他相關文章！