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

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

​作者 | 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/

责任编辑:武晓燕 来源: 51CTO技术栈
相关推荐

2020-10-25 09:04:46

数据加密数据泄露攻击

2010-09-25 08:55:29

2021-09-16 10:11:15

Dataphin 数据保护

2020-04-16 08:00:00

Ansible Vau敏感数据加密

2021-09-18 10:06:06

数据安全隐私计算大数据

2012-04-12 14:45:12

赛门铁克云南电网

2011-08-01 14:36:06

加密RSA

2021-10-28 09:42:38

代码编码开发

2010-05-14 13:50:57

2010-09-27 10:15:15

2021-08-27 16:26:11

敏感数据

2013-09-12 13:23:06

2018-09-14 14:48:01

2012-07-03 11:35:02

数据安全

2020-07-06 09:21:52

云平台云安全公共云

2010-03-05 11:03:06

DLP敏感数据

2021-03-19 11:13:07

SaaS云平台

2018-11-12 12:46:56

风险云计算用户

2021-03-23 14:34:25

敏感数据云安全漏洞

2020-12-20 17:30:17

数据匿名化敏感数据数据库
点赞
收藏

51CTO技术栈公众号