Securing Proxy Servers Against SSRF and Proxy Abuse

Server-Side Request Forgery is an attack class where an attacker causes a server to make HTTP requests to an unintended destination, typically an internal service the attacker cannot reach directly. SSRF became a standalone OWASP Top 10 category in 2021 (A10:2021) because the expansion of cloud infrastructure created millions of new internal endpoints (metadata services, management APIs, container orchestration APIs) that are only separated from the public internet by network topology, not authentication.

Proxy configurations are among the highest-risk SSRF surfaces because their entire purpose is to forward connections to remote destinations. A proxy that accepts a user-supplied URL and fetches it without validating the destination is an SSRF vulnerability by construction. The same feature that makes a proxy useful for outbound data collection makes it dangerous when the request destination is not controlled.

Citation Capsule: OWASP documents three primary SSRF impact categories: accessing internal-only services behind firewalls, reading sensitive data from cloud provider metadata endpoints (AWS 169.254.169.254, GCP 169.254.169.254 and metadata.google.internal, Azure 169.254.169.254), and performing port scanning against internal hosts. Each of these was a factor in documented production incidents between 2018 and 2024 per OWASP SSRF Prevention Cheat Sheet (2024 update).

The proxy-specific SSRF risk is amplified when the proxy resolves DNS on the server side (which is the correct configuration for socks5h:// and correct CONNECT proxy operation). DNS resolution on the proxy means the attacker can supply a hostname that resolves internally, bypassing network-level checks that only filter on IP address. An attacker who controls a DNS record can also use DNS rebinding: the hostname resolves to a public IP during the allowlist check and then to an internal IP when the actual connection is made.

guide to proxy dns leak testing and mitigation

---

An open proxy is a proxy that forwards requests from any source without requiring authentication. Shodan indexes over 2 million open HTTP proxies at any given time, and the median time between a new open proxy appearing on the public internet and its first automated scan probe is under 4 hours, based on honeypot data published by the Shadowserver Foundation (2023).

The three primary abuse patterns for open proxies are traffic relaying, SSRF exploitation, and amplification abuse.

Traffic relaying. Attackers use open proxies to anonymise connections for spam, credential stuffing, and web scraping. The proxy operator's IP appears in target server logs, not the attacker's. This exposes the proxy operator to abuse complaints, IP reputation degradation, and potential legal liability depending on jurisdiction.

SSRF via relay. If the open proxy is deployed in a network segment with access to internal services (a cloud VPC, a corporate LAN), an attacker with access to the proxy can address requests to internal hostnames or IP ranges. The proxy then fetches internal resources on the attacker's behalf, bypassing perimeter firewalls entirely. This is the mechanism behind high-profile SSRF breaches in cloud environments.

Amplification and DDoS relay. Open proxies are used to amplify DDoS traffic. An attacker sends small requests to many open proxies, instructing each to fetch a large resource from a target. The bandwidth consumed at the target far exceeds what the attacker sent. UDP-based protocols running through proxies are particularly susceptible.

[UNIQUE INSIGHT] The most dangerous open proxy configuration is not the intentionally deployed proxy without authentication, but the accidentally open proxy created when a developer exposes an internal proxy endpoint on a public-facing port without a firewall rule. This happens with Docker containers (where published ports bypass iptables rules and bind to 0.0.0.0 by default) and with proxy middleware in web frameworks that binds to all interfaces. The Docker default network bridge publishes a port to 0.0.0.0 unless 127.0.0.1:port:port binding is explicitly specified; most developers do not discover this until after an incident. The OWASP Security Misconfiguration category (A05:2021) covers this pattern but proxy-specific examples are underrepresented in its documentation.

---

URL allowlists permit connections only to explicitly approved destinations. URL denylists block known-bad destinations while permitting everything else. For SSRF prevention, allowlists are the recommended architecture because denylists fail against attackers who use alternative representations of the same address.

A denylist blocking 169.254.169.254 (the AWS metadata endpoint) can be bypassed using:

• Decimal encoding: 2852039166 (the integer representation of the IP)
• Octal encoding: 0251.0376.0251.0376
• Hexadecimal: 0xa9fea9fe
• IPv6 mapping: ::ffff:169.254.169.254
• A DNS record pointing to 169.254.169.254
• DNS rebinding: resolves to a public IP during the check, internal IP at connection time

An allowlist blocks all of these by default because none of them match an approved destination entry.

Implementing an effective URL allowlist:

1. Define the exact set of hostnames and ports that the proxy is permitted to forward to.
2. Resolve allowlisted hostnames to their current IP addresses and check both the hostname AND the resolved IP against the allowlist.
3. Reject any request where the resolved IP falls within private address ranges defined in RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), the loopback range (127.0.0.0/8), the link-local range (169.254.0.0/16), and IPv6 equivalents, unless that specific range is explicitly approved.
4. Implement a DNS TTL enforcement check: re-resolve the hostname immediately before the connection is opened, not only during the initial validation step. This closes the DNS rebinding window.

introductory guide to how proxy servers and ip addressing work together

---

An unauthenticated proxy reachable from the public internet is an open proxy by definition, regardless of intent. Authentication limits proxy access to authorised clients and creates an audit trail linking requests to identities. Two authentication models are in standard use: IP-based whitelisting and credential-based authentication (Basic Auth, Digest, or token).

IP whitelisting. The proxy only accepts connections from pre-approved client IP addresses. This is simple and adds no latency, but it requires the clients to have stable outbound IPs and breaks when clients are on dynamic IPs, NAT, or cloud environments with variable egress IPs.

Credential authentication. The proxy requires a username and password (HTTP Proxy-Authorization header, RFC 7235) or a bearer token. This works from any client IP but requires secure credential management: credentials must be rotated, stored in environment variables rather than source code, and transmitted only over TLS.

For forward proxies handling HTTPS traffic, authentication must occur at the CONNECT request stage (before the TLS tunnel is established) because the proxy cannot inject an authentication challenge once the tunnel is open. For SOCKS5, authentication is part of the protocol handshake per RFC 1928 (method 0x02 = username/password, defined in RFC 1929 by Leech, 1996).

Key access control rules for production proxy deployments:

• Bind the proxy listener to the specific IP addresses that require access, not to 0.0.0.0. Use 127.0.0.1 for local-only access or a private VPC IP for internal access.
• Disable the TRACE and TRACK HTTP methods at the proxy level. These methods can be exploited to read authentication headers in Cross-Site Tracing (XST) attacks.
• Configure a short connection timeout (30-60 seconds for standard use) to prevent connection hold-open abuse that consumes file descriptor limits.
• Set a maximum request size limit to prevent request smuggling amplification and memory exhaustion.
• If running Squid, Nginx, HAProxy, or another named proxy software, review the vendor's security advisories and apply patches within your organisation's standard patching window. Known proxy software CVEs are weaponised quickly because proxy servers are internet-facing.

---

Network-level egress filtering enforces destination restrictions independently of application-layer controls, providing a second layer of defence when URL validation logic contains bugs or is bypassed. A proxy that forwards only to allowlisted destinations at the application layer should be paired with firewall rules that enforce the same allowlist at the packet level.

Firewall-based egress rules. Configure outbound firewall rules on the proxy host to permit only the TCP/UDP destinations that the proxy is authorised to reach. In cloud environments, this maps to Security Group rules (AWS), Firewall Rules (GCP), or Network Security Groups (Azure) on the subnet containing the proxy instance.

Blocking link-local ranges at the network level. The 169.254.0.0/16 range (link-local, RFC 3927) hosts cloud metadata endpoints. A network-level rule dropping all outbound packets from the proxy to this range closes the metadata SSRF vector at the hypervisor layer, even if the application-layer check is bypassed. In AWS, this is configurable as an outbound Security Group deny rule for the proxy's security group.

DNS filtering. Deploy a DNS resolver for the proxy host that blocks resolution of internal domain names to public-facing proxy consumers. If the proxy is used for external data collection, its DNS resolver should only resolve public domains. Split-horizon DNS configurations where internal names resolve differently on internal hosts can be used to ensure that the proxy's resolver returns NXDOMAIN for internal service names.

Port restrictions. Restrict outbound connections from the proxy to the ports required for its function. A scraping proxy that only needs HTTP and HTTPS has no legitimate reason to connect outbound on port 22 (SSH), port 3306 (MySQL), port 6379 (Redis), or other internal service ports. Allowlisting only ports 80 and 443 outbound eliminates entire classes of lateral movement.

---

Cloud provider metadata endpoints are the most valuable SSRF targets in modern infrastructure because they serve temporary IAM credentials, instance identity documents, and bootstrap configuration. The 2019 Capital One breach demonstrated the consequences of leaving this vector open: an attacker used SSRF to query the AWS EC2 metadata service at 169.254.169.254, retrieved an IAM role credential, and used that credential to access S3 buckets containing approximately 100 million customer records. The OCC fined Capital One $80 million.

AWS Instance Metadata Service v2 (IMDSv2). AWS introduced IMDSv2 in 2019 as a response to SSRF exploitation of the metadata endpoint. IMDSv2 requires a PUT request to http://169.254.169.254/latest/api/token with a X-aws-ec2-metadata-token-ttl-seconds header to obtain a session token, then uses that token in subsequent GET requests. An SSRF attacker making a simple GET request cannot obtain credentials because the first-step PUT requires the token header. Enforcing IMDSv2 on EC2 instances hosting proxy infrastructure is a mandatory baseline:

# Enforce IMDSv2 on a running EC2 instance (AWS CLI)
aws ec2 modify-instance-metadata-options \
  --instance-id i-1234567890abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

GCP metadata endpoint. Google Cloud's metadata endpoint is at http://metadata.google.internal/ and also responds on 169.254.169.254. GCP requires a Metadata-Flavor: Google header on metadata requests, which SSRF attacks typically do not include. Verify that the proxy does not forward arbitrary headers from user-supplied requests that could satisfy this requirement.

Azure Instance Metadata Service (IMDS). Azure's IMDS at http://169.254.169.254/metadata/ requires the Metadata: true header. Same principle applies: ensure the proxy does not forward user-controlled request headers to link-local addresses.

Network ACL for metadata endpoint. Regardless of cloud provider, configure an outbound Network ACL (or security group rule) on the subnet containing the proxy to explicitly deny all traffic to 169.254.169.254/32. This operates below the instance OS level and cannot be bypassed by application vulnerabilities on the proxy host.

[PERSONAL EXPERIENCE] During a security review of a web scraping infrastructure running on AWS, a forward proxy deployed in a public subnet was accepting connections from the application layer without destination validation. A test request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ returned the EC2 instance role credentials in cleartext through the proxy response. The proxy had no URL allowlist, no authentication, and IMDSv1 was still active on the instance. The fix required three changes: adding a destination IP blocklist for 169.254.0.0/16 at the application layer, enforcing IMDSv2 via the instance metadata options API, and adding an outbound security group deny for 169.254.169.254/32. The review also found that the proxy was binding on 0.0.0.0:8080, making it accessible from any host within the VPC, not only the intended application servers.

---

Preventive controls reduce the attack surface but do not eliminate all risk. Logging and anomaly detection provide the signal needed to identify abuse in progress and trace incidents after the fact. Proxy access logs are high-value forensic evidence and should be treated accordingly.

Minimum logging fields per request:

• Timestamp (ISO 8601, millisecond precision)
• Client IP and port
• Destination hostname and resolved IP
• Destination port
• HTTP method and status code
• Bytes transferred (request and response)
• Connection duration
• Authentication identity (username or client cert CN)
• User-Agent string

Anomaly signals to alert on:

• Requests destined for RFC 1918, loopback, or link-local IP ranges (these should never appear in a correctly configured allowlist proxy)
• Unusually high request rates from a single authenticated identity (may indicate credential compromise)
• Connections to non-standard ports from a proxy that should only use 80/443
• Failed authentication spikes (credential stuffing or scanning for unauthenticated endpoints)
• DNS resolution results that differ from the expected IP for an allowlisted hostname (potential DNS hijack or rebinding attempt)

Log retention. Proxy access logs should be retained for a minimum of 90 days in a write-once storage location (S3 Object Lock in Compliance mode, Azure Immutable Blob Storage, or equivalent). Incident response timelines frequently exceed the default 7-30 day retention periods of standard log aggregation tools, and attackers who compromise a proxy host often delete local logs first.

Periodic allowlist audits. Allowlisted destinations should be reviewed quarterly to remove entries for decommissioned services, verify that IP ranges remain valid for the permitted hostnames, and confirm that no new internal address ranges have been inadvertently added during infrastructure changes.

guide to proxy dns leak testing and mitigation

---