Coders Conquer Security 基础设施即代码系列 - 使用来自不可信来源的组件

我们的“基础设施即代码”（IaC）系列课程即将结束，很高兴能帮助像您一样的开发者踏上 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 环境中，代码应如下所示：

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

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

除了使用安全代码库外，还应建立补丁管理流程，在整个软件生命周期内持续监控组件。此外，应使用 NVD 或 CVE 等工具检查所有客户端和服务器端组件的安全警报。最后，删除随外部代码一同引入的任何未使用或不必要的依赖项和功能。

通过遵循这些步骤，开发者可以更安全地利用外部资源，而不会意外地在应用和代码中引入漏洞。

查看 Secure Code Warrior 博客页面，深入了解此漏洞以及如何保护您的组织和客户免受其他安全缺陷的侵害。您还可以 申请演示 Secure Code Warrior 培训平台中的 IaC 挑战，以保持您的网络安全技能精进且与时俱进。