Burp's support for invisible proxying allows non-proxy-aware clients to connect directly to a Proxy listener. This option is sometimes useful if the application you are targeting employs a thick client component that runs outside of the browser, or a browser plugin that makes its own HTTP requests outside of the browser's framework. Often, these clients don't support HTTP proxies, or don't provide an easy way to configure them to use one.
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:
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.
There are two methods for resolving this problem:
A related problem arises if the non-proxy-aware client does not include a Host header in its requests. Without this header, when processing non-proxy-style requests, Burp cannot determine which destination host the requests should be forwarded to. Again, there are two methods for resolving this problem:
There are various options for configuring the server SSL certificates used by Burp Proxy listeners. The default option, of automatically generating a certificate for each destination host, may sometimes not work with invisible proxying. Non-proxy-aware clients negotiate SSL directly with the listener, without first sending a CONNECT request identifying the destination host that the client is seeking to contact. Many clients, including browsers, support the "server_name" extension in the Client Hello message, which identifies the destination host that the client wishes to negotiate with. If this extension is present, Burp uses it to generate a certificate for that host in the normal way. However, if the extension is not present in the Client Hello message, Burp will fail over to using a static self-signed certificate instead.
As with redirection of outbound requests, there are two methods for resolving this problem:
Get help and join the community discussions at the Burp Suite Support Center.
This release introduces a new scan check for second-order SQL injection vulnerabilities. In situations where Burp observes stored user input being returned in a response, Burp Scanner now performs its usual logic for detecting SQL injection, with payloads supplied at the input submission point, and evidence for a vulnerability detected at the input retrieval point.