程序员征服基础设施即代码安全系列：传输层保护不足

如果您是一位开发人员，想要了解如何在组织中开始部署安全的基础设施即代码（IaC），那么您来对地方了。这是我们 IaC 系列的下一篇章，旨在提升您在 IaC 安全最佳实践方面的水平。

在开始之前，您上一期的挑战完成得如何？如果您已经掌握了不安全加密的相关知识，那么在深入探讨细节之前，让我们来看看您对传输层保护不足的了解程度：

想要了解更多并获得满分吗？请继续阅读：

在上一篇文章中，我们讨论了通过安全加密来保护应用程序和程序所存储的重要或个人数据的重要性。强大的加密技术是最后一道完美的防线。即使攻击者窃取了数据，如果数据经过了强加密，那么这些文件中的信息依然是安全的。

然而，保护静态数据只是完整数据防御体系的一部分。当合法用户需要访问受保护的数据时，数据必须传输给他们。有时，应用程序也会在整体工作负载中与其他程序共享数据。如果传输层未受到保护，就会面临外部窃听和未经授权的内部查看风险。因此，传输层保护不足可能会引发严重问题。

这是一个常见问题。OWASP 安全组织甚至专门设立了一个页面来介绍传输层保护不足。

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

如果您没有充分保护传输层，那么技术娴熟的黑客很容易利用中间人攻击等技术，拦截用户与应用程序之间传输的信息。这种窃听最危险的地方在于，它几乎完全无法被任何内部网络安全平台或扫描工具检测到，因为它发生在您的网络和控制范围之外。

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

services:
 nginx:
   image: localhost:5000/scw_nginx
   build: ./nginx
   secrets:
     - nginx_cert
     - nginx_key
   volumes:
     - type: bind
       source: ./nginx/nginx.conf
       target: /etc/nginx/nginx.conf
       read_only: yes
   ports:
     - 80:8443
   networks:
     - frontend
   deploy:
     restart_policy: *default-restart_policy
     resources: *default-resources_policy

上述 Nginx 服务配置不会加密或保护连接，使得通过该链路交换的所有信息都容易受到各种攻击或窃听。

server {
       server_name scw-dev-blog.org;
       listen 8443;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           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 $scheme;
       }
   }

通常，发现传输层被窃听的第一个信号，是大量被盗的用户密码出现在随后的攻击中。如果客户信息、财务记录或重要的公司机密等其他数据通过不安全的传输层被窃取，您可能根本意识不到自己已经遭到入侵。

不仅用户与应用程序之间的传输层需要保护。在后端，许多应用程序之间以及与工作流中更后端的服务器之间也存在通信。虽然这些内部通信通常不易受到外部窃听，但它们可能会将数据暴露给网络内的用户，而这些用户可能并未获得查看某些高度机密或敏感信息的授权。

正确保护传输层以实现全面的数据安全

保护传输层的最佳时机是在应用程序创建过程中。这一过程始于构建安全的基础设施。对于网站，所有内容都应通过 HTTPS 进行处理。切勿混用 HTTP 和 HTTPS 基础设施。您甚至应该将站点设置为自动将不安全的 HTTP 请求重定向到 HTTPS 基础设施。

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

server {
       server_name scw-dev-blog.org;
       listen 8443 ssl;
       ssl_protocols TLSv1.2 TLSv1.3;
       ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
       ssl_prefer_server_ciphers on;
       ssl_certificate /run/secrets/nginx_cert;
       ssl_certificate_key /run/secrets/nginx_key;
       access_log /dev/stdout;
       error_log /dev/stderr;
       location / {
           proxy_pass http://wordpress:8080;
           proxy_set_header Host $http_host;
           proxy_set_header X-Forwarded-Host $http_host;
           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 $scheme;
       }
   }

在该示例中，所有与 Nginx 服务的连接均已进行强加密。Nginx 配置的 server 部分仅包含 listen 8443 ssl ，以强制使用 SSL 来保护连接。

为保护数据免受内部威胁，开发人员应采用 TLS 1.2 等强大的传输层加密协议。一旦部署了 TLS 1.2 或同等协议，就应彻底从基础设施中移除 SSL v2 等较弱的协议，并禁止其再次使用。

请始终牢记，只有当静态数据和传输层都得到充分保护时，应用程序的安全性才算完整。这样才能确保数据在内部以及传输给授权外部用户时，都能获得端到端的全面保护。
请查看 Secure Code Warrior 博客页面，深入了解此漏洞，以及如何保护您的组织和客户免受其他安全缺陷的侵害。您还可以 申请演示 Secure Code Warrior 培训平台，以保持您的网络安全技能精进且与时俱进。