If you are using a thick client component which cannot be configured to use a proxy, you can force it to talk to Burp Proxy instead of the actual destination host by performing the following steps:
- Modify your operating system hosts file to resolve the relevant destination hostnames to your loopback address (127.0.0.1), for example:
- For each destination port used by the application (typically 80 and 443), start a proxy listener on this port of your loopback interface, and configure the listener to support invisible proxying.
Previously, you could work around this problem by getting Burp to rewrite the Host header, or by using multiple machines with different DNS configurations for your testing. Now, things are much easier, because you can configure hostname resolution within Burp, to override the resolution provided by your operating system:
With this configuration, Burp will redirect outbound requests to the correct destination IP addresses, based on the Host header within each request. All being well, you should be able to intercept and forward traffic to multiple external domains, despite the thick client not itself supporting proxy connections.
One further complication may arise if your client does not include a Host header in its requests. If you are only dealing with one destination host, this is easily resolved: you can configure your proxy listener to redirect all traffic to a specific IP address. If you are dealing with multiple destination hosts, things get trickier again. You may be able to use Burp Extender to figure out the host based on the URL or other features of the request, and insert the correct Host header. Or you may be left with running Burp on multiple machines, and using your hosts file to redirect traffic for each destination host to a different intercepting machine.