敏感数据暴露，留给Git的时间只有20秒！

​作者 | codingwoman

译者 | 布加迪

策划 | 言征

大家可能都会面临这样直冒冷汗的情形：在使用Git进行版本控制时不小心推送了重要的密钥或超大文件？要知道，在敏感数据公开暴露20秒后，再去删除这些密钥可能已经为时太晚了！

人非圣贤，孰能无过？本文会分享介绍几个笔者在用的好技巧，这样在Git时，再也不用担惊受怕了。

一、永远不要推送非必要的文件和信息

Git中一类不需要的内容是非常大的文件。如果不小心提交了一个大文件到存储库，这肯定会限制你拉取或推送文件所需的时间；如果文件大于100MB，甚至还会显示错误。

其次，作为软件开发圈中的一员，这个忠告应该听过很多次：永远不要将机密信息推送到存储库。拥有芝麻粒大点资源的攻击者就可以通过窃取泄露的密文（secrets）和密钥来危及许多GitHub用户。然而，许多同行却对此不太当回事。

因此，我想分享几个统计数据。

我能进行另一个提交后删除它吗？

不。事实上，这比刚才的那件事还要危险。不要天真地以为，当他们从存储库中删除文件后，文件再也访问不了。这正是Git的用途所在。它会跟踪你的文件版本历史记录，以便你在想要恢复更改时可以恢复。

通过以下列方式进行提交以删除文件，你无异于将网上的陌生人引向存放密文的位置。

$ git commit –m “Remove api key”

只需你搜索一下，就可以看到这有多频繁。更明确地说，截止2023年1月5日笔者撰写这篇文章期间，在GitHub上搜索查询“remove api key”，返回了100万+提交，查询“remove password”返回了735K+提交。

随着ChatGPT大行其道，人们试图编写Python脚本来试用它，我发现无数的OpenAI API密钥散布在GitHub的各个角落。

这将引发严重后果！

二、那该怎么办？

当我们考虑从Git历史记录中删除提交时，首先想到的是立即将分支的顶端更改为旧的提交。这使我们安全地回到密钥不存在于存储库中的时候。

1 $ git reset <SHA1>
2 $ git commit -am message
3 $ git push -f <remote-name> <branch-name>

1.但已有一段时间了，是否为时太晚？

好吧，如果你遇到的问题与大文件有关，总是可以使用git filter-branch从历史记录中删除过去的信息/文件。此外，还有一个极好极简单的方法，我常常使用它。

见识一下BFG-Repo-Cleaner！这是一个用Scala编写的工具，可以删除大文件（比如预训练的模型或无法丢弃的大PDF文件）或麻烦的blob（比如API密钥、密码和密文），其功能就像git filter-branch，但速度更快。

GitHub的官方推荐也建议使用BFG-Repo-Cleaner来清除文件。

说明：我最近被告知git filter-branch已被弃用。现在可以使用git filter-repo或直接使用上面提到的BFG工具。

2.可以松口气了吗？

不，还不能松口气。当然，你可以随时使用这个工具删除大文件。然而，在将不必要的凭据推送到公共存储库之前，仍然应该小心为好。如果你最近在GitHub上泄露了密文，应该尽快用上面提到的工具收回密文。

此前，有一篇名为《Git会有多糟糕？揭秘公共GitHub存储库中的密文泄露》的论文首次全面深入分析了GitHub上的密文泄露。研究人员在文中评估了两种不同的挖掘密文的方法：一种能够实时发现99%的新提交的含有密文的文件，另一种利用了覆盖13%的公共存储库的大快照，其中一些可以追溯到GitHub创建时的快照。

• 你认为大多数被发现的密钥都用于测试吗？好吧，告诉你一个可怕的消息：研究人员估计，所有发现的密文中89.10%是敏感信息。
• 几个趋势：密文减少最明显的时候是在发现后的第一个小时，所有发现的密文中6%被移除。存在时间超过一天的密文往往长期存在——第一天结束时，12%以上的密文消失了，而16天后，只有19%的密文消失了。密文和文件被删除的速度大大超过代码库被删除的速度：用户没有删除代码库，而是创建新的提交以删除文件或密文。
• 最后，最重要的结论是：发现GitHub上分享的密文的平均时间为20秒左右，从半秒到4分钟不等，密文在一天中的什么时间被推送没有任何影响。所以在你不小心推送之后，留给你弥补的时间，比想象的要少得多。

三、结语

GitHub应该对可能暴露密文的提交，实行严格得多的政策或检查。或者至少将新注册的帐户引到相应的说明文档发出警告。笔者认为这对于刚开始踏上编程之旅的新人来说尤为重要。开发人员（尤其是新手）应该知道如何安全地公开源代码，以及忽视这么做可能面临的后果。

如何才能避免意外提交？这里给出几点建议：

• 避免使用像git add.或git commit-a这样的catch-all命令，而是使用git add filename。单独暂存文件也可以更好地跟踪提交方面的更改。你总是可以在流行的文本/源代码编辑器（比如Visual Studio Code）的源代码控制组件中使用暂存选项。
• 始终查看你的文件更改。使用git diff--cached，密切关注工作树上的变化。
• 还有其他类型的工具可以帮助你避免提交像git-secrets这样的密钥。
• 你还可以使用预提交钩子。

原文链接：http://www.codingwoman.com/git-the-good-the-bad-and-the-ugly/