Ticket #202 (closed design: duplicate)
security considerations for DNS rebinding
|Reported by:||email@example.com||Owned by:|
|Component:||p1-messaging||Severity:||Active WG Document|
Quoting Maciej Stachowiak:
Hello HTTP WG,
A discussion of DNS Spoofing and DNS Rebinding came up on the W3C Web Apps Working Group. Someone pointed out the RFC2616 Security Considerations subsection on DNS Spoofing. This led me to notice that RFC2616 and the latest HTTPbis internet drafts not only lack a mention of DNS rebinding in their security considerations, but actually have requirements that increase the risk of DNS spoofing.
DNS spoofing is addressed here: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#dns.spoofing>
DNS rebinding is a different type of attack than DNS spoofing. DNS spoofing typically involves binding the hostname of the victim to the IP of the attacker. This is done by fully controlling DNS on the local network or via DNS cache poisoning. Users attempting to visit the victim site then secretly end up loading content from a different host, possibly leading them to reveal confidential information.
DNS rebinding is almost the reverse - the attacker's domain name is bound to the victim's IP. This is used for an attack like so:
1) User loads a page from the attacker's domain. 2) Attacker serves his own DNS record with a very short TTL. 3) Attacker changes his DNS record to point to victim IP. 4) Script in the attackers page loads fresh resources on a short timeout - they are now coming from the victim's IP, but because they are labeled with the attacker's domain name, they are accessible due to the same-origin policy.
This won't allow access to resources protected by cookies, but it *does* allow attackers to read arbitrary resources from firewall-protected internets, where being inside the firewall is the only access restriction.
The DNS Spoofing security considerations subsection has a requirement that actually increases the risk of DNS rebinding attacks. It says that "If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they must observe the TTL information reported by DNS". Clients that follow this advice will be at greater risk than if they give cached DNS lookup results a floor on time-to-live, or keep a DNS resolution result "pinned" so long as any resource from that domain is active. Those are the simplest client-side mitigation strategies for DNS rebinding attacks. If DNS lookups are cached in the browser for a minimum of, say, an hour, there is much less risk of a DNS rebinding attack, because the attacker must get the user to keep a page open for at least an hour to be able to perform the rebinding attack.
DNS rebinding can also be defended against with complete effectiveness if servers always check the Host header. A server attacked via DNS rebinding will get an unexpected value in the Host header - the attackers hostname instead of any of its own.
HTTPbis should address this threat in the security considerations section, and should strongly consider making it a MUST-level requirement for servers to check that the Host header is a host they serve. Currently it actually says: "An origin server that does not allow resources to differ by the requested host may ignore the Host header field value when determining the resource identified by an HTTP/1.1 request" <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#the.resource.identified.by.a.request>. A server that takes advantage of that allowance may be at greater security risk.
If HTTP had a requirement to check the Host header and all servers followed it, then the risk of DNS rebinding attacks would be eliminated for conforming servers. Meanwhile clients can only implement mitigation strategies that are only partially effective or inordinately complex or both. And client-side protections can risk breaking completely valid DNS round-robin load balancing setups.