August 2011 Archives

Internet Explorer and the .NET Framework are hardcoded not to send requests for "127.0.0.1" or "localhost' through a proxy. So if you're testing an application that communicates with a service bound to the loop back interface it's not straight forward to intercept the traffic using Burp or another intercepting proxy. In IE9 they fixed this, by adding <-localhost> to the "do not use proxy" list will override this behavior. However if you're testing on an older version of IE you will have to use a work around.

Most articles on the web will tell you to use the IP address or machine name of the server you are testing. Which works fine if the service is bound to 0.0.0.0 or the public interface. However, if the service is bound to 127.0.0.1 you cannot reach the service via the machine name or the public interface IP. One option is to setup a tunnel using netcat, stunnel, socat, etc to forward requsts from the public interface to the loopback interface. Or you can use dns. The hardcoded restriction only triggers if the url has the string 127.0.0.1 or localhost in it. Requests to 127.0.0.2 or a domain that resolves to 127.0.0.1 are sent through the proxy.

So depending on your level of access to the system, you can add an entry in c:\windows\system32\drivers\etc\hosts for l0calhost , like this:127.0.0.1 l0calhostOr you can create a dns entry for a domain you control that resolves to 127.0.0.1. If you are running bind that should look like this (remember to update the serial number too):loopback.yourdomain.com IN A 127.0.0.1

You can now intercept the traffic for the service through the proxy by using http://l0calhost/ or http://loopback.yourdomain.com/