GitHub惊天安全毛病：删除的仓库竟能永远访问

引言

近日，GitHub 被曝出一个严重的安全毛病，引发了广泛关注。开源安全软件公司 Truffle Security 的安全研究员 Joe Leon 发现，在 GitHub 上删除的代码仓库实际上仍然可以被访问。这一发现震惊了整个开源社区。本文将详细探讨这一安全毛病的发现过程、其技术细节及其对 GitHub 用户的影响。
发现过程

在 Joe Leon 的研究中，他发现当用户在 GitHub 上删除一个 fork 的仓库时，实际上提交到该仓库的数据仍然可以被访问。这一问题的严重性在于，即便原始仓库被删除，fork 仓库的提交数据也仍然存在，且可以通过提交的哈希值来访问。
具体操纵步调

• 用户 fork 一个公共仓库。
  
• 用户向 fork 仓库提交数据。
  
• 用户删除 fork 仓库。
  

尽管用户认为这些数据已经被删除，但实际上仍可以通过原始仓库访问这些数据。这意味着，删除操纵在数据掩护方面实际上是无效的。
技术细节

GitHub 的这一问题源自于其处置惩罚删除仓库的方式。当用户删除一个仓库时，GitHub 只是删除了仓库的引用，但提交的数据仍然生存在其底层存储中。更令人担忧的是，任何人只要知道提交的哈希值，就可以访问这些提交的数据。
CFOR（Cross Fork Object Reference）毛病

Truffle Security 引入了一个新的安全术语 CFOR（Cross Fork Object Reference）来形貌这一毛病。CFOR 意味着当一个仓库 fork 可以访问另一个 fork 中的敏感数据时，就会出现这种毛病。用户只需要提供 commit 的哈希值，就可以直接访问提交的数据。
SHA-1哈希暴力破解

GitHub 允许使用短 SHA-1 值来引用提交，而短 SHA-1 值最小为 4 个字符。由于 4 个字符的 SHA-1 值只有 65,536 种大概性，这使得暴力破解这些值变得相对容易。一旦破解了哈希值，用户就可以访问到相关的提交数据。
案例研究

研究人员在一段视频中展示了如何使用这一毛病。他们 fork 了一个仓库，提交数据后删除了 fork 仓库，结果仍然可以通过原始仓库访问“已删除”的数据。更令人担忧的是，研究人员在一家大型 AI 公司的 3 个经常被 fork 的公共代码仓库中，轻松找到了 40 个有用的 API 密钥。
GitHub 的回应

GitHub 将 CFOR 视为一种设计特性，而非毛病。他们认为这是故意为之的设计，符合其预期。GitHub 的官方文档也形貌了这种举动。这一回应引发了广泛争议，因为这种设计显然存在安全隐患。
平台的处置惩罚方式

固然悬空提交是 git 中的一个概念，并不属于 GitHub 的功能，但每个平台对于悬空提交的处置惩罚方式是差异的。Bitbucket、GitLab 和 GitHub 都保存这些提交，只要用户把握了标识符就可以访问这些数据。
影响和建议

这一安全毛病对使用 GitHub 的企业和个人用户构成了严重的安全隐患。他们的机密数据大概会无意中袒露在组织的公共 GitHub 仓库中。为了防止数据泄漏，Truffle Security 建议用户在发现提交了敏感信息后，应立即更换密钥，而不是仅仅删除相关的仓库或引用。
总结

GitHub 的这一设计特性袒露了其在数据删除和掩护方面的庞大缺陷。尽管 GitHub 将其视为功能，但这一毛病显然需要引起器重。希望 GitHub 能重新思量其立场，为用户提供更安全的数据掩护机制。
未来预测

未来，GitHub 或其他代码托管平台大概需要引入新的功能，以允许用户永久删除提交的数据，并确保 fork 之间的数据隔离。同时，用户在使用这些平台时也需要更加谨慎，避免提交敏感信息。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。