login

Burp Suite, the leading toolkit for web application security testing

Burp Proxy: Invisible Proxying

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.

Redirecting Inbound Requests

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.0.0.1        example.org 

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.

Invisible Proxy Mode

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

Host: example.org

whereas the corresponding non-proxy-style request looks like this:

GET /foo.php HTTP/1.1

Host: example.org

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.

Redirecting Outbound Requests

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:

Handling SSL Certificates

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:

User Forum

Get help from other users, at the Burp Suite User Forum:

Visit the forum ›

Monday, October 20, 2014

v1.6.06

This release includes some major enhancements to the Scanner engine. Burp can now automatically report the following new types of issues: Perl code injection, PHP code injection, Ruby code injection, Server-side JavaScript code injection, File path manipulation, Serialized object in HTTP message, Client-side JSON injection, Client-side XPath injection, Document domain manipulation, Link manipulation, and DOM data manipulation.

See all release notes ›

Copyright © 2014 PortSwigger Ltd. All rights reserved.