Register now or log in to join your professional community.
make it invisible to users by applying WCCP or policy based routing to forward all traffic for specific ports to the proxy
You can effectively force the non-proxy-aware client to connect to Burp by modifying your DNS resolution to redirect the relevant hostname, and setting up invisible Proxy listeners on the port(s) used by the application.
For example, if the application uses the domain name example.org, and uses HTTP and HTTPS on the standard ports, you would need to add an entry to your hosts file redirecting the domain name to your local machine:
127.1.1.1
To receive the redirected requests, you would also need to create invisible Burp Proxy listeners on 127.0.0.1:80 and 127.0.0.1:443. The non-proxy-aware client will then resolve the domain name to your local IP address, and send requests directly to your listeners on that interface.
Using DNS to redirect client requests to the local listeners is easy enough, but the need for a special invisible proxy mode arises because the resulting requests will not be in the form that is normally expected by an HTTP proxy.
When using plain HTTP, a proxy-style request looks like this:
GET http://example.org/foo.php HTTP/1.1
whereas the corresponding non-proxy-style request looks like this:
GET/foo.php HTTP/1.1
Normally, web proxies need to receive the full URL in the first line of the request in order to determine which destination host to forward the request to (they do not look at the Host header to determine the destination). If invisible proxying is enabled, when Burp receives any non-proxy-style requests, it will by parse out the contents of the Host header, and use that as the destination host for that request.
When using HTTPS with a proxy, clients send a CONNECT request identifying the destination host they wish to connect to, and then perform SSL negotiation. However, non-proxy-aware clients will proceed directly to SSL negotiation, believing they are communicating directly with the destination host. If invisible proxying is enabled, Burp will tolerate direct negotiation of SSL by the client, and again will parse out the contents of the Host header from the decrypted request.
When running in invisible mode, Burp will by default forward requests on to destination hosts based on the Host header that was parsed out of each request. However, because you have modified the hosts file entry for the relevant domain, Burp itself will resolve the hostname to the local listener address, and unless configured differently will forward the request back to itself, creating an infinite loop.
Do you need help in adding the right keywords to your CV? Let our CV writing experts help you.
