A non-proxy-aware client, in this context, is a client that makes HTTP requests but has no easy way to configure proxy options, or has no proxy support at all.
Common examples of non-proxy-aware clients are thick client applications or browser plugins that do not use the browser's proxy options. Burp's support for invisible proxying allows non-proxy-aware clients to connect directly to a proxy listener. This allows Burp to intercept and modify traffic based on target mappings.
Architecturally, this works by setting up a local DNS entry for the remote target that the non-proxy-aware client communicates with. This DNS entry can be made in the local hosts file, as follows:
127.0.0.1 example.orgThe client then communicates with 127.0.0.1 instead of the actual IP address of example.org. To complete the circuit, local listeners would have to be set up with invisible Burp proxy support on port 80 (or whatever other port the server is listening on). The non-proxy-aware client will then resolve the domain name to 127.0.0.1, and send requests directly to the listener on that interface.
Burp, by default, will forward requests to the destination based on the host header that was obtained from the request header of the client. However, an interesting problem presents itself here. As the DNS entry for the destination has been set to 127.0.0.1, Burp will resolve the destination incorrectly and forward the request to itself, creating a loop.
This can be fixed by using an IP address instead of the domain name/hostname in the Redirect to host option under the Request handling tab, as shown in the following screenshot:
If the client communicates to multiple domains, then Burp's hostname resolution feature, available under the Project Options tab in the main window, can be used to individually map each request to the correct destination IP address. Each of these destinations should also be added to the host's file to ensure traffic destined for these hosts is sent via Burp.
