程序员以代码的形式征服安全基础架构系列——使用来自不可信来源的组件

我们的 “基础设施即代码” 系列已接近尾声，但能帮助像您这样的开发人员踏上 IaC 安全之旅真是太好了。

你玩过挑战赛吗？到目前为止你的分数是多少？在我们开始之前，让我们看看你已经对使用来自不可信来源的组件的陷阱了解了多少：

还有工作要做吗？继续阅读：

我们今天要重点关注的诱发漏洞的行为是使用来自不可信来源的代码，这种看似良性的做法会造成重大问题。使用开源代码和资源有很多好处。总的来说，它允许专家将他们的想法、工作甚至完成的代码贡献到像GitHub这样的存储库，供努力使程序或应用程序正常运行的其他人使用。使用完整的代码来管理程序函数，使开发人员不必在每次需要创建新应用程序时都重新设计轮子。

但是，使用来自不可靠、未经审查甚至潜在危险来源的代码片段会带来很大的风险。实际上，使用来自不可信来源的代码是主要和次要安全漏洞渗透到原本安全的应用程序中的最常见方式之一。有时，这些漏洞是由其创建者意外引起的。还存在潜在攻击者编写恶意代码的情况。然后共享该代码，希望能圈住受害者，他们会把它放到他们的应用程序中。

为什么使用来自不可信来源的代码很危险？

假设开发人员很着急，需要配置他们正在开发的应用程序。这可能是一个棘手的过程。因此，他们没有花费大量时间尝试找出所有可能的配置，而是进行谷歌搜索，找到已经完成看似完美的配置文件的人。尽管开发人员对编写代码的人一无所知，但将其添加到新应用程序中相对容易。可以在 Docker 环境中使用两行代码来完成：

运行 cd /etc/apache2/sites-available/ &&\
wget-O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf

现在 Docker 镜像将动态提取第三方配置文件。而且，即使文件经过测试后发现当时没问题，指针现在已嵌入到新应用程序的代码中这一事实也意味着存在永久依赖关系。几天、几周或几个月后，原始作者或破坏代码存储库的攻击者可能会修改该文件。突然之间，共享配置文件可以告诉应用程序的执行方式与预期的截然不同，可能会向未经授权的用户提供访问权限，甚至直接窃取数据并泄露数据。

使用共享资源的更好方法

如果您的组织允许使用外部来源的代码，则必须制定流程以确保安全完成。在评估外部代码的潜在用途时，请务必仅使用安全链接从官方来源获取组件。即便如此，你也永远不应该链接到外部源代码来提取这些代码，因为这会使过程脱离你的控制。相反，应将批准的代码带入安全的库中，并且只能在该受保护的位置使用。因此，在 Docker 环境中，代码将如下所示：

复制 src/config/default-ssl.conf /etc/apache2/sites-available/

与其依赖远程第三方配置文件，不如依赖这些文件的本地副本。这将防止进行任何意外或恶意的更改。

除了使用安全的代码库外，还应制定补丁管理流程，以便在整个软件生命周期中持续监控组件。还应使用 NVD 或 CVE 等工具检查所有客户端和服务器端组件是否存在安全警报。最后，移除任何未使用或不必要的依赖关系和功能，这些依赖项和功能可能会随外部代码一起使用。

通过执行这些步骤，开发人员可以更安全地使用外部资源，而不会意外地在应用程序和代码中引发漏洞。

来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台中存在的 IaC 挑战，让您的所有网络安全技能不断磨练并保持最新状态。