私有資料、刪除的內容可以永久訪問，GitHub官方：故意設計的-人工智慧-PHP中文網

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

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

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

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

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

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

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

想像以下工作流程：

在GitHub 上fork 一個公用儲存庫；
在GitHub 上fork 一個公用儲存庫；
你刪除你的fork 儲存庫。

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

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

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

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

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

存取已刪除儲存庫的資料

考慮如下工作流程：

你在Gitf你在他們fork 後提交數據，並且他們從不將其fork 存儲庫與你的更新同步；
你刪除整個存儲庫。
GitHub 將儲存庫和 fork 儲存庫儲存在儲存庫網路中，原始「上游」儲存庫充當根節點。當已 fork 的公共「上游」儲存庫被「刪除」時，GitHub 會將根節點角色重新指派給下游 fork 儲存庫之一。但是，來自「上游」儲存庫的所有提交仍然存在，並且可以透過任何 fork 儲存庫存取。

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

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

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

私有資料、刪除的內容可以永久訪問，GitHub官方：故意設計的也就是說，只要儲存庫有至少一個 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中文網其他相關文章！