服务器端请求伪造（SSRF）漏洞与防护（云原生与容器化环境防御篇） 描述 服务器端请求伪造（SSRF）漏洞允许攻击者诱使服务器向攻击者控制或指定的任意内部或外部网络地址发起请求。在云原生和容器化环境中，由于基础设施的动态性、服务网格的复杂性以及元数据服务的普遍存在，SSRF攻击的影响范围和潜在危害被急剧放大。攻击者可能利用此漏洞访问云服务商的实例元数据服务、容器编排平台（如Kubernetes）的API服务器、内部服务网格（如Istio）的控制平面，或容器运行时（如Docker守护进程）的Socket，从而可能实现权限提升、横向移动甚至集群控制。本知识点将深入剖析云原生环境下的SSRF攻击向量、利用技巧及纵深防御策略。 知识点讲解 第一步：理解云原生/容器化环境中的核心攻击面 云原生架构改变了传统网络边界，引入了新的内部服务和接口，这些常成为SSRF的目标： 云实例元数据服务 ：这是最典型的攻击面。例如，在AWS中， http://169.254.169.254/latest/meta-data/ 提供了实例的详细信息，包括IAM角色凭证。攻击者通过SSRF获取这些凭证，即可在云端执行与该角色权限对应的任何操作。 容器编排平台API ：Kubernetes API服务器通常在内网可访问（如 https://kubernetes.default.svc ）。如果Pod内的应用存在SSRF漏洞，攻击者可能利用其访问令牌（Service Account Token，默认挂载在 /var/run/secrets/kubernetes.io/serviceaccount/token ）通过API服务器管理集群资源。 服务网格控制平面 ：例如，Istio的Pilot或Citadel组件的管理接口如果暴露不当，可能被SSRF触及，用于修改流量规则或窃取证书。 容器运行时接口 ：Docker守护进程的Unix Socket（ /var/run/docker.sock ）或containerd的gRPC接口。如果容器内应用能通过SSRF向这些接口发送HTTP/HTTPS请求（需注意协议转换），则可能实现容器逃逸。 内部服务和功能即服务（FaaS） ：访问同一虚拟私有云（VPC）或服务网格内的其他微服务、数据库、消息队列，或触发无服务器函数。 第二步：攻击手法与利用链构建 攻击者需要结合环境特性，构建利用链： 探测与信息收集 ：利用SSRF尝试访问已知的元数据服务端点、Kubernetes默认服务域名、或常见的内部网段（如 192.168.0.0/16 , 10.0.0.0/8 ）。可通过观察响应差异、错误信息或延时进行盲测。 协议利用 ：许多HTTP库支持多种URL协议（如 file:// , gopher:// , dict:// ）。在容器内， file:// 协议可用于读取敏感文件（如Service Account Token）。某些库的协议处理不当可能导致对非HTTP服务的访问（如通过CR-LF注入模拟HTTP请求访问Redis）。 绕过过滤 ： DNS重绑定 ：攻击者控制一个域名，其DNS记录TTL极短，首次解析返回一个允许的外网IP（通过过滤），但第二次解析时返回目标内网IP（如 169.254.169.254 ）。服务器在第一次DNS查询后可能缓存IP，但攻击者可利用某些实现或TTL过期机制，使实际请求发送到内网地址。 URL解析歧义 ：利用 @ 、 # 、 ? 等符号，或注册指向内网IP的域名（如 169.254.169.254.nip.io ），绕过基于黑名单或主机名提取的过滤。 IPv6与IPv4表示 ：使用IPv6地址 [::ffff:169.254.169.254] 或十进制IP表示法绕过简单的字符串匹配。 权限升级与横向移动 ：获取到云凭证或Service Account Token后，使用AWS CLI、kubectl等工具执行后续攻击，如创建具有更高权限的实例、窃取S3数据、在集群中部署恶意Pod等。 第三步：纵深防御策略 防护需在多个层面构建防线： 应用层防护（白名单是黄金标准） ： 输入验证与白名单 ：严格验证用户输入的URL。如果业务功能只需访问特定外部服务，应建立固定的主机名/IP和端口白名单，并在代码中映射，而非让用户提供完整URL。 使用安全的URL解析库 ：使用标准库并统一解析策略，避免自行拼接。解析后，提取 hostname （而非 host ，以排除端口），并对其进行白名单校验。 禁用危险的URL协议和重定向 ：在应用使用的HTTP客户端库中，显式禁用 file:// 、 gopher:// 、 dict:// 等非必要协议。同时，禁用HTTP客户端自动跟随重定向的功能，或对重定向目标进行同样严格的白名单检查。 网络层隔离 ： 出口流量过滤 ：在Pod或容器级别，使用NetworkPolicy（Kubernetes）或安全组（云平台）限制出口流量。例如，只允许应用容器访问其必需的外部API和特定的内部服务（如数据库）， 明确拒绝访问云元数据服务IP（ 169.254.169.254 等）和Kubernetes API服务器集群IP 。 服务网格策略 ：利用Istio或Linkerd的AuthorizationPolicy，定义细粒度的服务间通信规则，即使存在SSRF，请求也无法到达非授权的服务。 专用节点/实例 ：运行可能处理用户可控URL的应用的节点，应使用不分配高权限IAM实例配置文件或关闭元数据服务的专用实例。 身份与访问管理（IAM）最小权限原则 ： 云凭证 ：附着到实例的IAM角色应遵循最小权限原则，仅授予其必需权限。可进一步使用IAM Condition条件限制请求源IP。 Kubernetes Service Account ：为每个Pod/Deployment创建专属的Service Account，并绑定仅具有必要权限的Role。 避免使用 default Service Account或授予其过宽权限（如 cluster-admin ） 。可考虑禁用自动挂载Service Account Token（ automountServiceAccountToken: false ）。 运行时与环境加固 ： 容器镜像安全 ：使用最小化基础镜像，移除非必要的网络工具（如 curl , ncat ）。 只读文件系统 ：将容器根文件系统挂载为只读，防止通过 file:// 协议写入文件。对必需的可写目录（如临时目录）使用单独卷。 非特权用户运行 ：容器内应用不应以root用户运行。 Seccomp/AppArmor策略 ：应用定制的Seccomp配置文件限制危险系统调用（如 connect 到特定地址），或使用AppArmor策略限制网络访问。 监控与响应 ： 日志记录 ：详尽记录所有出站HTTP请求的目标地址、响应状态码。尤其关注对元数据服务、内部网络段的访问尝试。 威胁检测 ：使用SIEM或云安全态势管理（CSPM）工具，设置规则检测异常行为，如从应用实例发往元数据服务的请求、使用非常见协议的出站连接、或Service Account Token被用于非常规API操作。 安全测试 ：在CI/CD管道中集成动态应用安全测试（DAST）和交互式应用安全测试（IAST），专门扫描SSRF漏洞。定期进行红队演练，模拟云环境下的SSRF攻击链。 总结 云原生环境下的SSRF防护是一个系统工程，需从应用代码、网络策略、身份权限、运行时容器和环境监控等多个层面实施纵深防御。核心在于： 应用层实施严格的白名单验证、网络层强制隔离关键服务、遵循最小权限原则管理身份凭证，并通过强化容器运行时环境来限制攻击面。 通过上述组合策略，可以显著降低SSRF漏洞在云原生架构中被成功利用的风险。