DNS rebinding: prevention?

Shumon Huque shuque at isc.upenn.edu
Wed Aug 8 14:48:27 UTC 2007

On Tue, Aug 07, 2007 at 06:26:40PM -0700, Chris Buxton wrote:
> Mark,
> Please explain where you think the flaw is.
> Is it the job of the web browser to understand what IP space is  
> private and what is public? Is it the job of the browser to create  
> its own DNS cache? Isn't it valuable that a web browser be responsive  
> to changes in DNS?
> Web servers should always use name-based virtual hosts, with no  
> default site, in order to somewhat prevent the attack (but the  
> attacker can still use this method to find out what IP addresses have  
> web servers, or other open ports). But there is a plethora of reasons  
> why this is often not done. And FTP service doesn't have the concept  
> at all, but the attack can work just as well against FTP as HTTP.
> In order to protect private data which should be freely available  
> within an intranet but completely hidden from the outside, without  
> crippling the browser's ability to adapt to DNS changes, one of the  

Perhaps this is where the real flaw is. This thread seems to have
focussed on flaws in the browser security model and that is certainly 
partly true. But the other flawed security model that is doing even 
more to facilitate this threat is the notion that you can install
a perimeter firewall around hosts interacting with the Internet at
large, and then rely on source IP address based authorization to
protect internal resources. How about protecting those resources
with proper strong (cryptographic) authentication instead? That would
appear to solve the problem more generally - since the next time it
will be another application that is similarly tricked and not a
web browser.


More information about the bind-users mailing list