现在有点忙，简单机翻，没时间精译了，觉得拉跨可以看原文。

您可以访问GitHub 上已删除的分支、已删除的存储库甚至私有存储库中的数据。而且这些数据将永远可用。GitHub 知道这一点，并有意这样设计。

对于所有使用 GitHub 的组织来说，这都是一个巨大的攻击媒介，因此我们引入了一个新术语：跨分支对象引用 (CFOR)。当一个存储库分支可以访问另一个分支的敏感数据（包括来自私有和已删除分支的数据）时，就会发生 CFOR 漏洞。与不安全的直接对象引用类似，在 CFOR 中，用户提供提交哈希来直接访问提交数据，否则这些数据对他们来说是不可见的。

我们来看几个例子。

访问已删除的 Fork 数据

考虑一下 GitHub 上的常见工作流程：

1. 你 fork 了一个公共存储库
2. 你将代码提交到你的 fork 中
3. 你删除了你的 fork

您提交到 fork 的代码还能访问吗？应该不能，对吧？您已将其删除。

是的。而且可以永久访问。不受你控制。

在下面的视频中，您将看到我们分叉一个存储库，向其提交数据，删除分叉，然后通过原始存储库访问“已删除”的提交数据。https://youtu.be/eF-_mTvk7TQ

您可能认为只要知道提交哈希，您就会受到保护。但事实并非如此。哈希是可发现的。稍后会详细介绍。

我们多久能找到一次已删除的分叉中的数据？

相当常见。我们调查了一家大型 AI 公司的一些（实际上是 3 个）常用分叉的公共存储库，并从已删除的分叉中轻松找到了 40 个有效 API 密钥。用户模式似乎是这样的：

1. 分叉 repo。
2. 将 API 密钥硬编码到示例文件中。
3. <做工作>
4. 删除分叉。

但这更糟糕，它也会反过来起作用：

访问已删除的存储库数据

考虑以下场景：

1. 您在 GitHub 上有一个公共 repo。
2. 一个用户分叉了你的 repo。
3. 您在他们分叉之后提交数据（并且他们永远不会将其分叉与您的更新同步）。
4. 您删除了整个 repo。

在他们分叉你的 repo 之后你提交的代码还能被访问吗？

是的。

GitHub 将存储库和分支存储在存储库网络中，原始“上游”存储库充当根节点。当已分支的公共“上游”存储库被“删除”时，GitHub 会将根节点角色重新分配给下游分支之一。但是，“上游”存储库中的所有提交仍然存在，并且可以通过任何分支访问。

在下面的视频中，我们创建了一个 repo，对其进行分叉，然后展示在删除原始 repo 后，如何仍可以通过分叉访问未与分叉同步的数据。https://youtu.be/vgMllgNzm-8

这并非只是一些奇怪的极端情况。上周发生了以下事情：

我向一家大型科技公司提交了一个 P1 漏洞，表明他们意外提交了一名员工 GitHub 帐户的私钥，而该帐户对整个 GitHub 组织具有重要访问权限。他们立即删除了该存储库，但由于它已被分叉，因此我仍然可以通过分叉访问包含敏感数据的提交，尽管分叉从未与原始“上游”存储库同步。

这里的含义是，只要至少有一个存储库的分支，任何提交到公共存储库的代码都可以永远访问。

情况变得更糟了。

访问私人仓库数据

考虑在 GitHub 上开源新工具的常见工作流程：

1. 您创建一个私人仓库，该仓库最终将公开。
2. 您创建该 repo 的私有内部版本（通过分叉）并提交不打算公开的功能的附加代码。
3. 您将您的“上游”存储库公开，并将您的 fork 保持私有。

您的私人功能和相关代码（来自步骤 2）是否可以被公众查看？

是的。在您创建工具的内部分支和开源工具期间提交的任何代码都可以在公共存储库中访问。

在将“上游”存储库公开后，对私有分支所做的任何提交都不可查看。这是因为更改私有“上游”存储库的可见性会导致两个存储库网络 - 一个用于私有版本，一个用于公共版本。

在下面的视频中，我们演示了组织如何在维护私有内部分支的同时开源新工具，然后展示了如何通过公共版本访问私有内部版本的提交数据。https://youtu.be/7BE3Nt_P1yc

不幸的是，这种工作流程是用户和组织开发开源软件最常用的方法之一。因此，机密数据和秘密可能会在组织的公共 GitHub 存储库中无意中暴露。

您实际上如何访问数据？

通过直接访问提交。

GitHub 存储库网络中的破坏性操作（如上述 3 种情况）会从标准 GitHub UI 和常规 git 操作中删除对提交数据的引用。但是，这些数据仍然存在并且可以访问（如果您知道提交哈希）。这是 CFOR 和 IDOR 漏洞之间的关联 - 如果您知道提交哈希，则可以直接访问不适合您访问的数据。

提交哈希是 SHA-1 值。

如果用户知道他们想要查看的特定提交的 SHA-1 提交哈希，他们可以直接在端点导航到该提交：https://github.com /<user/org>/<repo>/commit/<commit_hash>。他们会看到一个黄色横幅，解释“此提交不属于此存储库的任何分支，可能属于存储库外部的分支。”

你从哪里获得这些哈希值？

提交哈希可以通过 GitHub 的 UI 进行暴力破解，特别是因为 git 协议允许在引用提交时使用短 SHA-1 值。短 SHA-1 值是避免与另一个提交哈希冲突所需的最小字符数，绝对最小值为 4。所有 4 个字符 SHA-1 值的密钥空间为 65,536 (16^4)。暴力破解所有可能的值相对容易实现。

例如，考虑 TruffleHog 存储库中的此提交：

要访问此提交，用户通常访问包含完整 SHA-1 提交哈希的 URL：https://github.com/trufflesecurity/trufflehog/commit/07f01e8337c1073d2c45bb12d688170fcd44c637

但用户不需要知道整个 32 个字符的 SHA-1 值，他们只需要正确猜出短 SHA-1 值，在本例中为07f01e。

https://github.com/trufflesecurity/trufflehog/commit/07f01e

但更有趣的是，GitHub 公开了一个公共事件 API 端点。您还可以在由第三方管理的事件存档中查询提交哈希，该存档保存了过去十年 GitHub 之外的所有 GitHub 事件，即使在存储库被删除后也是如此。

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-变化可见性

我们很欣赏 GitHub 对其架构的透明度，并花时间清楚地记录用户应该期望在上述实例中发生什么。

我们的问题是这样的：

普通用户将私有和公共存储库的分离视为安全边界，并且可以理解地认为，任何位于私有存储库中的数据都不能被公共用户访问。不幸的是，正如我们上面所记录的，这并不总是正确的。此外，删除行为意味着数据的破坏。正如我们上面所看到的，删除存储库或分支并不意味着您的提交数据实际上被删除。

启示

我们从中得到一些启示：

1. 只要存在一个分支，对该存储库网络的任何提交（即：“上游”存储库或“下游”分支上的提交）将永远存在。这进一步巩固了我们的观点：安全地修复公共 GitHub 存储库中泄露的密钥的唯一方法是通过密钥轮换。我们花了很多时间记录如何轮换最常泄露的机密类型的密钥 - 在此处查看我们的工作：howtorotate.com。
2. GitHub 的存储库架构必然存在这些设计缺陷，不幸的是，绝大多数GitHub 用户永远不会理解存储库网络的实际工作方式，并因此而降低安全性。
3. 随着秘密扫描的发展，我们希望能够扫描存储库网络中的所有提交，我们将对可能不属于我们自己的秘密发出警报（即：它们可能属于分叉存储库的人）。这将需要更认真的分类。
4. 虽然这三种情况令人震惊，但这甚至没有涵盖 GitHub 存储存储库中已删除数据的所有方式。查看我们最近的帖子（以及相关的 TruffleHog 更新），了解如何还需要扫描已删除分支中的机密。

最后，虽然我们的研究重点是 GitHub，但值得注意的是，其他版本控制系统产品中也存在其中一些问题。