DNS Rebinding Lab

DNS Rebinding — Bypassing the Same-Origin Policy

What Is DNS and Why Does TTL Matter?

Every time your browser navigates to a website, it must first translate the human-readable hostname (such as attacker.example.com) into a numeric IP address that routers can forward packets to. This translation is performed by the Domain Name System (DNS). Your operating system sends a query to a recursive resolver, which traces the authoritative chain — root nameservers, top-level domain nameservers, and finally the domain's own authoritative nameserver — until it receives the IP address associated with the hostname.

To avoid repeating this lookup on every request, the result is cached. The Duration for which it may be cached is encoded in the DNS response itself as the Time-To-Live (TTL), measured in seconds. A TTL of 300 means the cached record expires after five minutes. Once the TTL elapses, the browser (or operating system resolver) must perform a fresh DNS lookup before sending the next request to that hostname. This is entirely normal behaviour — it allows domain operators to update their IP addresses without permanently stranding users.

Attackers can set the TTL on their own domain's DNS records to an extremely low value — sometimes as low as one second. This is legal and configurable by anyone who controls a domain.

The Same-Origin Policy

The Same-Origin Policy (SOP) is the browser's most fundamental access-control boundary. It prevents a script loaded from one origin from reading the response of a request made to a different origin. An origin is the triplet of scheme + hostname + port. For example, https://app.internal.corp:8080 is a different origin from https://app.internal.corp:9000 (different port) and from http://app.internal.corp:8080 (different scheme).

When a page at https://attacker.example.com tries to fetch data from https://internal-router.local, the browser blocks the response: the origins differ. This is the security boundary that DNS rebinding is designed to defeat.

How DNS Rebinding Breaks the SOP

DNS rebinding exploits the gap between what the SOP knows (origin as a string) and what the network does (resolve the hostname to an IP address at request time). The attack proceeds as follows:

1. The attacker registers a domain — for example, evil.attacker.com — and runs an authoritative DNS server for it.
2. The victim visits http://evil.attacker.com/. The DNS server returns the attacker's real public IP with a very low TTL (one second).
3. The page loads JavaScript that sits idle until the TTL expires.
4. After TTL expiry, the JavaScript initiates a new request to http://evil.attacker.com/api. The browser must re-resolve the hostname. This time the attacker's DNS server returns a private IP address — for example, 192.168.1.1 (the victim's home router admin panel).
5. The browser sends the HTTP request to 192.168.1.1, but with the Host header set to evil.attacker.com and with the origin still recorded as http://evil.attacker.com. The SOP check passes because, from the browser's perspective, the request and the response share the same origin.
6. The internal service responds (it has no authentication because it assumes it is only reachable from within the private network). The JavaScript on the attacker's page reads the response freely.

Threat Model

The attack requires: (a) the victim to visit the attacker-controlled page while on a network with accessible internal services; (b) the internal service to lack per-request authentication or Host header validation. Common targets include home router admin panels, IoT device dashboards, locally running development servers, and corporate intranet applications that rely solely on network-perimeter access controls. The attacker gains the ability to read internal data, modify device configuration, or pivot further into the internal network — all from a page the victim opened in their own browser.