最近，一個訊息震驚開源社群：在 GitHub 上刪掉的內容、私有儲存庫的資料都是可以永久訪問的，而且這是官方故意設計的。
開源安全軟體公司 Truffle Security 在一篇部落格中詳細描述了這個問題。
Truffle Security 引入了一個新術語：CFOR（Cross Fork Object Reference）：當一個儲存庫 fork 可以訪問另一個 fork 中的敏感資料（包括來自私有和已刪除 fork 的資料）時，就會出現 CFOR 漏洞。
與不安全的直接物件引用類似，在 CFOR 中，使用者提供提交（commit）雜湊值就可以直接訪問提交資料，否則這些資料是不可見的。
以下是 Truffle Security 部落格原文內容。
訪問已刪除 fork 儲存庫的資料
想象如下工作流程：
在 GitHub 上 fork 一個公共儲存庫；
將程式碼提交到你的 fork 儲存庫中；
你刪除你的 fork 儲存庫。
那麼，你提交給 fork 的程式碼應該是不能訪問了對吧，因為你把 fork 儲存庫刪除了。然而它卻永久可以訪問，不受你控制。
如下影片所示，fork 一個儲存庫，向其中提交資料，再刪除 fork 儲存庫，那麼可以透過原始儲存庫訪問「已刪除」的提交資料。
這種情況普遍存在。Truffle Security 調查了一家大型 AI 公司 3 個經常被 fork 的公共儲存庫，並從已刪除的 fork 儲存庫中輕鬆找到了 40 個有效的 API 金鑰。
訪問已刪除儲存庫的資料
考慮如下工作流程：
你在 GitHub 上有一個公共儲存庫；
使用者 fork 你的儲存庫；
你在他們 fork 後提交資料，並且他們從不將其 fork 儲存庫與你的更新同步；
你刪除整個儲存庫。
那麼，使用者 fork 你的儲存庫後你提交的程式碼仍然可以訪問。
GitHub 將儲存庫和 fork 儲存庫儲存在儲存庫網路中，原始「上游」儲存庫充當根節點。當已 fork 的公共「上游」儲存庫被「刪除」時，GitHub 會將根節點角色重新分配給下游 fork 儲存庫之一。但是，來自「上游」儲存庫的所有提交仍然存在，並且可以透過任何 fork 儲存庫訪問。
這種情況不是個例，上週就發生了這樣一件事情：
Truffle Security 向一家大型科技公司提交了一個 P1 漏洞，顯示他們意外地提交了一名員工 GitHub 帳戶的金鑰，而該帳戶對整個 GitHub 機構擁有重要訪問許可權。該公司立即刪除了儲存庫，但由於該儲存庫已被 fork，因此仍然可以透過 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-forks/what-happens-to-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