Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A hostname check only protects an SSRF-sensitive request if the checked address is the address the HTTP client actually connects to. Resolve the destination, validate its IPv4 and IPv6 addresses against your network policy, then bind the connection to a permitted address while keeping the original hostname for the HTTP Host header, TLS SNI, and certificate verification. Recheck every redirect and ensure retries or fallback connections cannot perform a fresh, unchecked lookup.
How DNS rebinding bypasses SSRF validation
Server-side request forgery (SSRF) occurs when an application can be induced to make requests to destinations an attacker chooses. A common defense is to check a submitted URL’s hostname against a policy. That check is not enough if the HTTP client resolves the hostname again later.
An attacker-controlled hostname can return an address that passes validation, then return a private, loopback, link-local, or otherwise prohibited address when the client makes its connection. If the client performs that second lookup without applying the same policy, the request can reach a destination the application intended to block. OWASP warns that domain allowlisting alone does not prevent DNS rebinding and identifies a second unchecked lookup as a bypass risk (OWASP SSRF Prevention Cheat Sheet).
The essential invariant is simple: the address evaluated by the destination policy must be the address used for the socket connection. The USENIX Association’s 2024 study describes reusing the resolved, validated address as IP pinning (SSRF vs. Developers: A Study of SSRF-Defenses).
#1 Best Overall
What a custom resolver must do
A custom resolver or equivalent connection hook should make the decision at the boundary between name resolution and the actual connection. It must not merely return a safe-looking result to an HTTP client that can independently resolve the hostname afterward.
- Parse and constrain the URL. Use a well-defined URL parser, accept only the schemes the feature needs, and extract the hostname and port according to that parser’s rules. Avoid treating string checks as URL validation.
- Resolve the hostname. Obtain the relevant A and AAAA answers. Apply the destination policy to both address families rather than checking only IPv4 or assuming that an IPv4 result represents the whole destination.
- Apply the network policy. For known service destinations, prefer an explicit allowlist. For features that must contact arbitrary hosts, classify and reject prohibited address ranges with a carefully maintained policy. The policy should cover every address the connection mechanism might select.
- Bind the connection to an approved address. Give the HTTP transport the validated address, or use a connection hook that dials that address directly. Ensure the transport cannot silently perform another hostname lookup and substitute a different address.
- Keep hostname identity intact. Connect to the pinned address, but retain the requested hostname for the HTTP
Hostheader, TLS SNI, and certificate verification. Replacing the hostname everywhere with the IP can break virtual hosting and TLS identity checks; disabling certificate verification is not a safe workaround. - Preserve the rule across connection paths. Apply the same enforcement to retries, alternate addresses, fallback connections, and any connection-pool behavior that can establish a new socket. A validated address from one attempt does not authorize an unchecked lookup on the next.
OWASP points to curl’s custom address resolution as an example of directing a connection to a chosen address while preserving hostname behavior. The exact API depends on the HTTP library: confirm that it pins the socket destination and retains the hostname for HTTP and TLS identity, rather than assuming that a resolver callback alone provides those guarantees.
How to handle redirects, retries, and IPv6
Redirects
Disable automatic redirect following for requests subject to SSRF controls, or intercept each redirect and run the complete URL and destination checks again. A redirect can change the hostname, scheme, port, or address, so permission for the initial URL does not grant permission to its target. Reject schemes the feature does not support at every hop.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Retries and fallbacks
A retry that triggers a new DNS lookup creates another opportunity for rebinding. Pin and validate the address for each new connection, or reuse an already approved address where the transport’s semantics make that safe. Check alternate-address selection and fallback behavior as well; they must not escape the policy applied to the first attempt.
IPv4 and IPv6
Evaluate A and AAAA answers against the same destination policy. If the application blocks a destination on IPv4 but leaves an IPv6 route unchecked, the client may still reach it through IPv6. The connection code must use only an address that has passed policy, regardless of which address family the resolver or operating system prefers.
Choosing an allowlist or network policy
| Application need | Suitable policy | Main trade-off |
|---|---|---|
| The application contacts a known set of services | Explicit hostname or destination allowlist, with resolved addresses still checked and pinned | The list must remain complete and maintainable; admitting an unexpected host expands what the feature can reach. |
| The application must fetch arbitrary destinations | Network classification that rejects prohibited destinations, applied to every resolved address and actual connection | Coverage and ongoing policy updates are operational responsibilities; denylist-style defenses are easier to bypass than a narrow allowlist. |
These policies are not substitutes for connection binding. An allowlisted hostname can still be subject to rebinding, while an address-classification policy is ineffective if the HTTP client uses a different address from the one checked. OWASP favors allowlisting when expected targets are known and warns that denylisting is bypass-prone; the USENIX study also discusses challenges with denylist-based defenses.
Rank #4
Operational defenses that complement connection pinning
- Use DNS monitoring for detection. Resolver ordering and monitoring can help surface unexpected internal or local answers. They do not ensure that the address checked is the one used for a connection, so they cannot replace pinning.
- Limit cloud metadata exposure. In cloud deployments, SSRF can be used to target instance metadata services. OWASP describes AWS IMDSv2 as an additional defense against some SSRF cases. Treat it as defense in depth alongside application-layer destination controls, not as a substitute for them (OWASP SSRF Prevention Cheat Sheet).
- Test the actual transport path. Verify behavior for IPv4 and IPv6, redirect targets, connection retries, fallback paths, and hostname verification. A resolver unit test alone cannot establish that the eventual socket uses the validated address.
What the 2024 study’s counts do—and do not—show
The USENIX Association’s 2024 analysis reports that, within its sample of SSRF-capable flows, 38 had no validation, 26 used category allowlisting, 10 used denylisting, and 12 used regex. The authors also report finding no DNS-based defenses in the analyzed cases. These are study-sample findings, not population estimates; the categories should not be summed or compared without consulting the paper’s methods. They do not establish how common these practices are across all applications.
Quick Recap
Best Value
- Used Book in Good Condition
Implementation review checklist
- The URL parser accepts only intended schemes and handles hostname, port, and redirects consistently.
- Every relevant A and AAAA address is evaluated under a documented destination policy.
- The validated address is the address dialed; the HTTP client cannot perform an unchecked second lookup.
- The original hostname remains in use for HTTP
Host, TLS SNI, and certificate verification. - Redirects are disabled or each target is parsed, resolved, checked, and pinned anew.
- Retries, fallback connections, alternate-address selection, and new sockets follow the same policy.
- DNS monitoring and cloud metadata protections are treated as supplementary controls.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
