编码员征服安全基础设施即代码系列--使用来自不信任来源的组件

我们的 "基础设施即代码 "系列已接近尾声，但能帮助像你这样的开发者在IaC安全之路上走得很好。

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

仍有一些工作要做？继续阅读。

我们今天要关注的诱发漏洞的行为是使用来自不受信任的来源的代码，这种看似良性的做法正在造成大问题。使用开放源代码和资源有很多好处。一般来说，它允许专家将他们的想法、工作甚至是已完成的代码贡献给GitHub这样的存储库，供其他努力使程序或应用表现正常的人使用。使用已完成的代码来管理程序功能，使开发人员不必在每次需要创建新的应用程序时重新发明车轮。

然而，使用来自不可靠的、未经审查的、甚至有潜在危险的来源的代码片段会带来很多风险。事实上，使用来自不受信任的来源的代码是主要和次要安全漏洞潜入其他安全应用程序的最常见方式之一。有时，这些漏洞是由它们的创造者意外地诱发的。也有潜在攻击者编写恶意代码的情况。然后，这些代码被分享出来，希望能诱使受害者将其放入他们的应用程序中。

为什么使用来自不受信任来源的代码是危险的？

比方说，一个开发人员很匆忙，需要配置他们正在开发的一个应用程序。这可能是一个棘手的过程。因此，与其花大量的时间去研究每一种可能的配置，不如在谷歌上搜索一下，发现有人已经完成了一个看起来很完美的配置文件。尽管开发者对写代码的人一无所知，但将其添加到一个新的应用程序是相对容易的。它可以在Docker环境中使用两行来完成。

RUN 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博客页面，了解有关这一漏洞的更多见解，以及如何保护您的组织和客户免受其他安全缺陷的破坏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战，以保持你的所有网络安全技能得到磨练和更新。