On Feb 8, 2010, at 9:01 AM, Julian Reschke wrote: > Anne van Kesteren wrote: >>>>> - Considerations around DNS rebinding. >>>> >>>> Why would these be specific to XMLHttpRequest? >>> >>> These indeed apply to just about any specification that uses a same-origin >>> policy. But that's not a justification for ignoring them here. DNS >>> rebinding has been both obvious and overlooked for some 10-15 years, so >>> reminding reviewers and implementers of both the security risk and the >>> countermeasures would seem appropriate. >> But you could e.g. do this kind of attack using <img> or <form> as well. It >> seems this problem should be pointed out in the HTTP specification. >> ... > > Is re-binding == spoofing? Does > <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.3> help, or > does nit need to be updated (Thomas; HTTPbis will gladly accept your input > ;-).
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. 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. What the section you cited says 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. 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. If HTTP had that requirement and all servers followed it, then the risk of DNS rebinding attacks would be eliminated. Meanwhile clients can only do partially effective or inordinately complex mitigations to protect against this attack, and client-side protections can risk breaking completely valid DNS round-robin load balancing setups. Regards, Maciej
