Burp Proxy Options
This tab contains Burp Proxy settings for Proxy
listeners, interception of requests and
responses, response modification,
match and replace, and
miscellaneous options.
Proxy Listeners
A Proxy listener is a local HTTP proxy server that listens for incoming
connections from your browser. It allows you to monitor and intercept all
requests and responses, and lies at the heart of Burp's
user-driven workflow. By default, Burp creates a single listener on port 8080 of the
loopback interface. To use this listener, you need to
configure your browser to use 127.0.0.1:8080 as its proxy server. This default listener is
all that is required for testing virtually all browser-based web
applications.
Burp lets you create multiple Proxy listeners, and provides a wealth of
configuration options for controlling their behavior. You may occasionally
need to use these options when testing unusual applications, or working with
some non-browser-based HTTP clients.
Binding
These settings control how Burp binds the Proxy listener to a local
network interface:
- Bind to port - This is the port on the local interface
that will be opened to listen for incoming connections. You will need to
use a free port that has not been bound by another application.
- Bind to address - This is the IP address
of the local interface that Burp will bind to. You can bind to just the
loopback interface, or to all interfaces, or to any specific local IP
address. Note: if the listener is bound to all interfaces
or to a specific non-loopback interface, then other computers
may be able to connect to the listener. This may enable them to initiate outbound
connections originating from your IP address, and to access the contents of
the Proxy history, which may contain sensitive data such as login credentials.
You should only enable this when you are located on a trusted network.
Request Handling
These settings include options to control whether Burp redirects requests received
by this
listener:
- Redirect to host - If this option is configured,
Burp will forward every request to the specified host, regardless of the
target requested by the browser. Note that if you are using this option,
it may be necessary to configure a match/replace rule to rewrite the Host header in
requests, if the server to which you are redirecting requests expects a Host
header that differs from the one sent by the browser.
- Redirect to port - If this option is configured,
Burp will forward every request to the specified port, regardless of the
target requested by the browser.
- Force use of SSL - If this option is configured,
Burp will use HTTPS in all outgoing connections, even if the incoming
request used plain HTTP. You can use this option, in conjunction with
the SSL-related response modification options, to
carry out sslstrip-like attacks using Burp, in which an application that
enforces HTTPS can be downgraded to plain HTTP for a victim user whose
traffic is unwittingly being proxied through Burp.
Note that each of the redirection options can be used individually. So
for example, you can redirect all requests to a particular host, while
preserving the original port and protocol used in each original request.
Burp's support for invisible proxying allows
non-proxy-aware clients to connect directly to the listener. For more
details see the invisible proxying
help.
Certificate
These settings control the server SSL certificate that is presented to SSL
clients. Use of these options can resolve some SSL
issues that arise when using an intercepting proxy:
- You can eliminate SSL alerts in your browser, and the need to create SSL
exceptions.
- Where web pages load SSL-protected items from other domains, you can
ensure that these are properly loaded by the browser, without the need to
first manually accept the proxy's SSL certificate for each referenced domain.
- You can work with thick client applications that refuse to connect to
the server if an invalid SSL certificate is received.
The following options are available:
- Use a self-signed certificate - A simple self-signed SSL certificate is presented
to your browser, which always causes an SSL alert.
- Generate CA-signed per-host certificates - This is the default
option. Upon installation, Burp creates a unique, self-signed Certificate
Authority (CA) certificate,
and stores this on your computer to use each time Burp is run. When your browser
makes an SSL connection to a given host, Burp generates an SSL certificate
for that host, signed by the CA certificate. You can
install Burp's CA certificate
as a trusted root in your browser, so that the
per-host certificates are accepted without any alerts.
- Generate a CA-signed certificate with a specific hostname - This
is similar to the preceding option; however, Burp will generate a single
host certificate to use with every SSL connection, using the hostname you
specify. This option is sometimes necessary when performing invisible proxying,
because the client does not send a CONNECT request, and so Burp cannot identify
the required hostname prior to the SSL negotiation. As previously, you can
install Burp's CA certificate
as a trusted root.
- Use a custom certificate - This option enables you to load a specific certificate
(in PKCS12 format) to present to your browser. This option should be used if the
application uses a client which requires a specific server certificate (e.g.
with a given serial number or certification chain).
Interception Options
These settings control which requests and responses are stalled for
viewing and editing in the Intercept tab. Separate settings are applied to
requests and responses.
The "Intercept" checkbox determines whether any messages are intercepted.
If it is checked, then Burp applies the configured rules to each message to
determine whether it should be intercepted.
Individual rules can be activated
or deactivated with the checkbox on the left of each rule. Rules can be
added, edited,
removed, or reordered using the buttons.
Rules can be configured on practically any attribute of the message, including
domain name, IP address, protocol, HTTP method, URL, file extension, parameters,
cookies, header/body content, response code, content type and HTML page title.
You can configure rules to only intercept items for URLs that are within the
target scope. Regular expressions can be used to define complex matching conditions
for each attribute.
Rules are processed in order, and are combined using the Boolean operators AND
and OR.
These are processed with a simple "left to right" logic in which the
scope of each operator is as follows:
(cumulative result of all prior rules) AND/OR (result of current
rule)
All active rules are processed on every message, and the result after the
final active rule is applied determines whether the message is intercepted or
forwarded in the background.
The "Automatically update Content-Length" checkbox controls whether
Burp automatically updates the Content-Length header of the message when
this has been modified by the user. Using this option is normally essential
when the HTTP body has been modified.
Response Modification
These settings are used to perform automatic modification of responses. You can use these options to achieve various tasks by automatically rewriting
the HTML in application responses.
The following options may be useful to remove client-side controls over
data:
- Unhide hidden form fields
- Enable disabled form fields
- Remove input field length limits
- Remove JavaScript form validation
The following options may be useful for disabling client-side logic for
testing purposes (note that these features are not designed to be used as a
security defense in the manner of NoScript):
- Remove all JavaScript
- Remove <object> tags
The following options may be used to deliver sslstrip-like attacks
against a victim user whose traffic is unwittingly being proxied via Burp.
You can use these in conjunction with the listener option to
force SSL in outgoing requests to
effectively strip SSL from the user's connection:
- Convert HTTPS links to HTTP
- Remove secure flag from cookies
Match and Replace
These settings are used to automatically replace parts of requests and
responses passing through the Proxy. For each HTTP message, the enabled
match and replace rules are executed in turn, and any applicable
replacements are made.
Rules can be defined separately for requests and responses, and for
message headers and bodies. Each rule can specify a regex pattern to match,
and a literal string to replace it with.
For message headers, if the match condition matches the entire header and
the replacement string is left blank, then the header is deleted. If a blank
matching expression is specified, then the replacement string will be added
as a new header.
Miscellaneous
These settings control some specific details of Burp Proxy's behavior.
The following options are available:
- Use HTTP/1.0 in requests to server - This option controls whether Burp Proxy
enforces HTTP version 1.0 in requests to destination servers. The default
setting is to use whichever version of HTTP is used by the browser. However,
some legacy servers or applications may require version
1.0 in order to function correctly.
- Use HTTP/1.0 in responses to client - All current
browsers support both version 1.0 and 1.1 of HTTP. Since version 1.0 has a
reduced feature set, forcing use of version 1.0 can sometimes be useful to
control aspects of browsers' behavior, such as preventing attempts to
perform HTTP pipelining.
- Set response header "Connection: close" - This option
may also be useful to prevent HTTP pipelining in some situations.
- Unpack gzip / deflate - Most browsers accept gzip- and deflate-compressed
content from servers. In order to view or modify this content within Burp, it needs to be
unpacked into uncompressed form. This option controls whether Burp Proxy performs
this unpacking automatically.
- Disable web interface at http://burp - This option may
be useful if you are forced to configure your listener to accept connections on an unprotected interface, and wish to
prevent others gaining access to Burp's in-browser controls.
- Suppress Burp error messages - When certain errors
occur, by default Burp returns meaningful error messages to the browser. If
you wish to run Burp in stealth mode, to perform man-in-the-middle attacks
against a victim user, then it may be useful to suppress these error
messages to disguise the fact that Burp is involved.