I was checking the article hosts file on Wikipedia, and I found this:

Blocking access to servers of unwanted content by redirecting them to the local host ( may have security implications. As is accessible only by the host itself, connections might be trusted. The link to be followed may be crafted to launch an attack on the local host.

Although it does not cite any reference, I wonder if this is true.

I thought about using hosts file to block some web bugs and trackers. Is this safe or not?

4 Answers 4


My guess it that the Wikipedia author is referring to IE Security Zones, where the DNS name or IP address grants additional functionality to things like

  • ActiveX controls
  • Javascript
  • Execution of non-signed data
  • Access to internal (read corporate file server) data.

More info here

  • 2
    +1 This makes sense. (I'm not a IE/windows user). But additionally, wouldn't the attacker have to (a) get the 'ActiveX / javascript / non-signed executables' on to the client system and (b) install/turn on some service on the client machine to serve those activeX / javascript when a request for http://malicioussite.com/malicious.js gets translated to (e.g., install apache2 to serve malicious.js on localhost)? (At which point, this is more dangerous than finding malicious.js on the web as IE designates its trusted as it originated from localhost).
    – dr jimbob
    Feb 13, 2012 at 16:02

Imagine you are running a network service (e.g. HTTP) on your local machine. This is bound to both the loopback interface ( and an internet facing interface (

Now say you have a script on your machine that an attacker knows can be used to perform administrative tasks, but only if performed by an administrator.

The presumption is that your script only assumes the visitor is an administrator if they are connected from the server itself. An administrative function can be called using GET variables, like:

If a user tried to do this from the internet, the script could see that the connecting user was on a foreign IP and it would return with, say, HTTP 403.

Now you are browsing the internet on your server (silly you). You click on an attackers link whose domain name has been associated with something dodgy, and so it's in your hosts file. Now instead of this link taking you to http://blockeddomain.com/?droptable=foo&setpwd=bar, your own hosts file ensures that gets loaded instead.

Your database tables are dropped and the attacker compromises your authentication mechanisms.

Of course this is a very basic example and it requires many assumptions to be made. However this is one real world possibility of how such a setup could cause you a headache.

  • 1
    Good answer. However, there's nothing stopping those attackers from building a link to or http://localhost in the first place. I suppose the difference would be that upon inspection of the link it will become more obvious than someevildomain.com though.
    – Yoav Aner
    Feb 13, 2012 at 14:26
  • 2
    You should not use a client's IP address to restrict access to sensitive functionality as anything but a redundant line of defense. Client IP addresses can be easily changed in http request headers; the only problem with doing so is that the client won't receive the responses from the server. (But if they are trying to just delete information, that isn't a problem.) Furthermore, you should never have a password in a URL or its query (these are typically logged in the browser history and webserver logs), and you should never transmit passwords over http cleartext.
    – dr jimbob
    Feb 13, 2012 at 15:01

I don't see any danger if you are the one setting up your own /etc/hosts to block specific web bugs/trackers; however, I can easily imagine a scenario where an attacker can use /etc/hosts to redirect to localhost to do some malicious things.

For example, let's say an attacker designs a malicious clone of a web site (like amazon.com) and install it on a local webserver and edits /etc/hosts to redirect to amazon.com to localhost. A user on that computer going to amazon.com would not know the difference and likely would input confidential information to the malicious web app running on localhost (that may say send off that confidential information to elsewhere).

I wouldn't worry too much about redirects to localhost being 'trusted'; using a client's IP address as a means of authentication to give them privileges to alter information is a mistake in the design of a web app.

  • The question as I understood it, was about the risks associated with changing your own hosts file and pointing known malicious hostnames to your localhost (as a way to block yourself from accessing those malicious sites). You say that you "don't see any danger if you are the one...". There is however some danger, as I believe deed02392 articulated in their answer. I don't disagree that the danger of external malicious modification of your hosts file is probably far greater, but I wouldn't say there is no danger in altering your own hosts file in this way.
    – Yoav Aner
    Feb 13, 2012 at 15:34
  • @YoavAner - For deed02392 attack to work, you need (a) a client browsing to the webbug from a production server (shouldn't happen), (b) the webbug site to know of a specific URL that is a security hole in your application when accessed from localhost (very insecure design), and (c) the webbug site doesn't exploit it directly by using in their bug (which would always work), but instead decides to use http://malicioussite.com/?delete=data&security=none which only works if you used /etc/hosts to redirect malicioussite.com to
    – dr jimbob
    Feb 13, 2012 at 15:55
  • If you're worried about attackers editing hosts files to phish, then you should probably worry about DNS search paths more since they're a single point of failure. The only thing that the ability to edit hosts gets you over DNS search paths is that someone who is careful to go to http://amazon.com./ instead of http://amazon.com/ will fall afoul of hosts routing when they would be safe from DNS search path manipulation. Feb 13, 2012 at 21:03

Perhaps this is a better solution. Instead of using in the hosts file, wouldn't the net effect be the same - yet safer - to use

  • Unfortunately that isn't true on every operating system. It vastly depends on how the network stack interprets RFC1122, which defines as "this host on this network". When binding a listening socket it usually translates to "listen to any address on any interface", but on most unix-like operating systems (including OS X), it is equivalent to when establishing a connection, also. So in short, it's pretty much the same in this scenario.
    – mr_daemon
    Oct 11, 2015 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .