程序员以代码的形式征服安全基础架构系列：传输层保护不足

如果你是一名开发人员，想进一步了解在组织中开始部署安全基础设施即代码 (IaC) 时可以采取的步骤，那么你来对地方了。这是我们的 iaC 系列的下一章，旨在提升您在 IaC 安全最佳实践方面的水平。

在我们开始之前，你对上一期的挑战表现如何？如果你已经掌握了不安全的加密技术，那么在深入研究细节之前，让我们看看在传输层保护不足的情况下你会怎么做：

想了解更多信息并取得满分吗？继续阅读：

在上一篇文章中，我们讨论了使用安全加密技术保护应用程序和程序存储的任何重要或个人数据的重要性。如果你有很强的加密能力，它可以作为完美的最后一道防线。即使攻击者能够窃取这些数据，如果数据经过高度加密，则锁定在这些文件中的信息仍然受到保护。

但是，保护静态数据只是完整数据防御的一部分。每当有效用户需要访问受保护的数据时，都必须将其发送给他们。有时，应用程序还会与其他程序共享数据，这是总体工作负载的一部分。除非传输层受到保护，否则它很容易受到外部监听和未经授权的内部查看。因此，传输层保护不足可能会导致严重问题。

这是一个常见的问题。OWASP 安全组织甚至维护了整整一页关于 传输层保护不足。

为什么传输层保护不足很危险？

如果你没有充分保护传输层，那么熟练的黑客相对容易使用中间人攻击等技术拦截用户和应用程序之间流动的信息。这种窥探行为最危险的方面可能是，任何内部网络安全平台或扫描都几乎完全看不到它，因为它发生在你的网络和你的控制范围之外。

例如，在部署 Nginx 服务的 Docker 环境中：

服务：
nginx：
图片：本地主机：5000/scw_nginx
构建：。/nginx
秘密：
-nginx_cert
-nginx_key
体积：
-类型：绑定
来源：。/nginx/nginx.conf
目标：/etc/nginx/nginx.conf
只读：是
端口：
-80:8443
网络：
-前端
部署：
重启策略：*默认重启策略
资源：*默认资源政策

Nginx 服务配置不会加密或保护连接，因此通过该链接交换的所有信息都容易受到各种攻击或窥探。

服务器 {
服务器名称 scw-dev-blog.org;
听着 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers 开启；
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
位置/{
proxy_pass http://wordpress:8080;
proxy_set_header 主机 $http_host;
proxy_set_header X-Forwarded-Host $http_hos
proxy_set_header X-real-IP $remote_addr;
proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $方案;
}
}

通常，有人可能窥探您的传输层的第一个信号是在随后的攻击中使用大量被盗的用户密码。如果客户信息、财务记录或重要的公司机密等其他数据通过不安全的传输层被盗，您甚至可能永远不会意识到自己已被泄露。

而且，需要保护的不仅仅是用户和应用程序之间的传输层。在后端，许多应用程序相互通信，并与工作流程链中更远的服务器通信。尽管这些内部通信通常不易受到外部窥探，但它可能会将数据暴露给可能被允许访问网络但无权查看某些高度保护或敏感信息的用户。

妥善保护传输层以全面保护数据

最好在创建应用程序时保护传输层。这个过程从拥有安全的后端基础设施开始。对于网站，一切都应使用HTTPS完成。切勿混用 HTTP 和 HTTPS 基础设施。您甚至应该将您的站点设置为自动将不安全的 HTTP 请求路由到 HTTPS 基础架构。

在上面的示例中，保护传输层的正确方法是：

服务器 {
服务器名称 scw-dev-blog.org;
收听 8443 ssl；
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM: EDH+AESGCM;
ssl_prefer_server_ciphers 开启；
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
位置/{
proxy_pass http://wordpress:8080;
proxy_set_header 主机 $http_host;
proxy_set_header X-Forwarded-Host $http_hos
proxy_set_header X-real-IP $remote_addr;
proxy_set_header X-Forwarded-for $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $方案;
}
}

在该示例中，与 Nginx 服务的所有连接均经过高度加密。Nginx 配置的服务器部分仅包括 收听 8443 ssl 以强制 SSL 保护连接。

为了保护您的数据免受内部威胁，开发人员应使用强大的传输层加密协议，例如TLS 1.2。一旦您安装了 TLS 1.2 或其等效协议，应将诸如 SSL v2 之类的较弱协议从您的基础架构中完全移除，并自动禁止其使用。

请务必记住，只有在静态数据和传输层都得到充分保护后，保护应用程序才能完全完成。这样，无论是内部还是流向授权的外部用户时，您都可以保证对数据进行全面的端到端保护。
来看看 安全代码勇士 博客页面，详细了解此漏洞以及如何保护您的组织和客户免受其他安全漏洞的破坏。你也可以 试试演示 Secure Code Warrior 培训平台可让您的所有网络安全技能不断磨练并保持最新状态。