Server-Side Request Forgery Protections

In this lesson, you will learn how to harden your containerized cloud network configurations to prevent Server-Side Request Forgery (SSRF) from escalating into cloud-native privilege escalation.

The SSRF-to-Cloud-Metadata Threat

In container environments (like EKS, GKE, or AKS), your pods often have access to a local Instance Metadata Service (IMDS). If an attacker successfully tricks your C# application into making an outbound request to http://169.254.169.254/latest/meta-data/, they can potentially exfiltrate IAM role credentials attached to the node or pod. Since your application is already inside the internal network perimeter, traditional firewalls often overlook these requests.

Hardening Container Networking

To mitigate this, you must move beyond application-level validation and enforce network-level restrictions:

1. Network Policies (Kubernetes): Use NetworkPolicies to implement a "Default Deny" posture for egress traffic. Explicitly whitelist only the external dependencies your C# service requires (e.g., specific API endpoints). By blocking traffic to the metadata IP range entirely for application pods, you kill the primary vector of credential theft.
2. Identity-Based Access (Workload Identity): Transition away from node-level permissions. By using technologies like Azure Workload Identity or AWS IRSA (IAM Roles for Service Accounts), you map specific IAM roles to specific Kubernetes service accounts. This ensures that even if an attacker hits the IMDS, the metadata returned is scoped strictly to the pod’s minimal requirements, rather than the entire node's identity.
3. Application Egress Proxies: Force all outbound traffic through an egress gateway or proxy. Within your .NET code, use an IHttpClientFactory configured with a custom HttpMessageHandler that performs strict URL validation or utilizes a proxy that logs and blocks requests to reserved internal IP ranges (like 169.254.0.0/16, 10.0.0.0/8, or 172.16.0.0/12).

// Example of a protective outgoing check
var target = new Uri(userInputUrl);
if (target.IsLoopback || target.Host.Contains("169.254.169.254"))
{
    throw new InvalidOperationException("Prohibited target address.");
}

By combining strict egress network policies with scoped service identities, you ensure that even a successful SSRF exploit cannot reach your cloud provider's control plane.

Key Takeaway: Mitigate SSRF in containers by applying a "Default Deny" egress network policy and restricting service identities to the absolute minimum privileges required for your application.