A short TTL and a DNS swap turn the browser's same-origin policy into the attacker's delivery mechanism - every fetch from the loaded page hits the internal network, not the internet.
DNS rebinding turns the browser's same-origin policy inside out. An attacker controls a domain, sets its TTL to one second, and waits for the cache to expire. On the second DNS lookup, the server returns an internal IP address instead of the attacker's public one. From that moment, every fetch the loaded JavaScript issues goes to the internal network - and the browser permits it, because the origin never changed. The same-origin policy, designed to block cross-origin reads, becomes the mechanism that makes the attack work.
The attack is a TTL race split across two DNS responses. In phase one the attacker's domain resolves to their own public server with a one-second TTL. The victim loads the page, the browser caches the IP, and the attacker's JavaScript executes in a tab. In phase two the TTL expires, the browser re-queries, and the attacker's DNS responds with a private address - 10.x.x.x, 192.168.x.x, or 169.254.169.254. The origin is still attacker.example.com. The browser's same-origin check passes. Every subsequent XHR or fetch from the page now targets the internal host.
The internal service sees a request from a source IP inside the network, which it likely trusts. It returns data that should never cross the perimeter. The victim's browser relays each response body back to the attacker's origin through a websocket or a series of fetch callbacks - a covert channel through the victim's own browser.
A DAST scan cannot directly demonstrate a rebinding attack - that would require controlling external DNS infrastructure, which is outside the safe-probe boundary. What can be confirmed from the scan boundary are the two necessary preconditions: a DNS TTL low enough to open a rebinding window, and an internal service that accepts Host headers without validation. Either absent precondition blocks the attack entirely; both present together is the reachable finding.
# Precondition 1: measure the DNS TTL for the internal-facing domain dig +nocmd +noall +answer api.internal.example.com # api.internal.example.com. 30 IN A 10.0.1.100 # TTL 30 s - a rebinding window is viable # Precondition 2: does the service accept an arbitrary Host header? curl -sI -H "Host: attacker.example.com" http://10.0.1.100/api/v1/status # HTTP/1.1 200 OK Content-Type: application/json # Host header accepted without redirect or 400 - no Host validation # Precondition 3: does the service set Private Network Access headers? curl -sI -H "Origin: https://attacker.example.com" \ -H "Access-Control-Request-Private-Network: true" \ http://10.0.1.100/api/v1/status # No Access-Control-Allow-Private-Network header in response # Browser Private Network Access guard absent
A low TTL alone does not confirm the attack - the internal service must also accept requests routed through an unexpected Host header, and must not block the browser's pre-flight Private Network Access check. All three gaps together constitute reachable. Confirmed requires demonstrating that the browser actually delivers internal response data to the attacker's origin, which requires a controlled browser environment.
The rebinding mechanism is always the same. What the attacker can do after the swap depends entirely on which internal service answers on the resolved address. A cloud metadata endpoint that returns temporary IAM role credentials is a different class of finding from a forgotten developer debug server that happens to serve environment variables. The confirming artifact must identify the service - not just assert that the TTL is short.
| Internal service at resolved IP | Likely impact via rebinding | Severity |
|---|---|---|
| Cloud metadata (169.254.169.254) | IAM role credentials; full cloud account if policy is overpermitted | Critical |
| Kubernetes API server (:6443 / :8001) | Cluster admin via default or absent RBAC gate | Critical |
| Internal REST API (no authentication) | Data exfiltration scoped to service permissions | High |
| Router or switch admin panel | Network configuration change, VLAN pivot | High |
| Development debug server (env vars exposed) | Database credentials, API keys, session secrets | High |
Shortening an external domain's TTL does not help - the attacker controls their own DNS and sets a one-second TTL regardless. Blocking at the internal service is the durable control. Each service that should not be reachable from browser-originated traffic must validate the Host header against an explicit allowlist of expected hostnames before processing any request. A request where the Host field does not match a known value should return 400 or be dropped by the reverse proxy before the application layer ever sees it.
Chrome 98 and later enforce the Private Network Access specification: a browser will send a pre-flight OPTIONS request with Access-Control-Request-Private-Network: true before any cross-origin request to a private IP range. If the internal service does not respond with Access-Control-Allow-Private-Network: true, the browser blocks the main request. This is a meaningful defence-in-depth layer for modern browsers, but it is not the primary control: legacy browsers, mobile WebViews, and any non-browser client ignore the header entirely. Host-header validation at the network edge is what closes the gap for every client.
The proof bar is the same as any boundary test. A reachable finding carries the TTL measurement, the Host-header acceptance artifact, and the absent Private Network Access header - three independent facts, each with its confirming HTTP exchange. Severity is set by the service identified at the resolved IP, not by the rebinding window itself. A finding rated on the mechanism alone, without identifying what answers on the other side, is an incomplete report.