DNS Rebinding
DNS rebinding answers the first resolution with a public IP and later ones with a private address, letting public web pages bypass same-origin policy and reach internal services through the browser.
Definition
DNS rebinding flips a hostname between public and private addresses across TTLs. The victim browser loads the attacker page from the public IP, then the same hostname resolves to an internal IP, and same-origin policy sees one origin throughout. The page scripts then issue requests against internal admin panels, databases, and cloud metadata from inside the network.
Context and scope
The classic browser pivot into intranets. Modern mitigations: browsers block public-to-private resolves for some schemes, but filtering and home networks remain exposed. Testing tools like rebinder DNS services exist.
Common misconceptions
- Internal-only services are unreachable from browsers — the browser itself becomes the proxy; the request originates inside the perimeter
- Firewalls prevent it — the traffic is ordinary outbound DNS plus browser HTTP from an internal host, which default allow rules permit
- It requires special victims — any browser visiting a public page while inside the target network qualifies
Anti-patterns
- Exposing admin panels and home routers without authentication because they are not internet-routable
- Trusting requests by network position — believing source IP on the LAN implies a trusted device
- Relying on browser protections alone without authenticating internal services
Related concepts
Related examples
Authoritative source
What it is
Same-origin policy keys on hostname, not IP. If a hostname maps to different IPs over time, one origin spans both networks. The attacker controls the DNS zone and the TTLs, so the mapping changes on schedule.
How it works
The page fetches from attacker.example. First answer: the real public server serving JavaScript. After the short TTL expires, the same name resolves to 192.168.x.x. The script now issues fetches to the same origin, which the browser happily sends to the internal device, reading responses because origin never changed.
When to defend
Authenticate and authorize every internal service; network location is not identity. Block resolution of public names to private ranges at the resolver, or enforce resolvers for all clients. Home and OT networks are the recurring victims because routers ship unauthenticated LAN panels.
Pitfalls
Browser mitigations such as Local Network Access protections roll out gradually and vary by engine. TLS on internal services stops script from reading responses but not from sending blind requests. Pin internal hostnames in resolver policy rather than patching applications one by one.