Introduction Burp Suite Part II ( Proxy Tab)
Burp Proxy lies at the heart of Burp's user-driven workflow. It operates as a web proxy server between your browser and target applications, and lets you intercept, inspect and modify the raw traffic passing in both directions.
If the application employs HTTPS, Burp breaks the SSL connection between your browser and the server, so that even encrypted data can be viewed and modified within the Proxy.1. Intercepting
The Intercept tab is used to display and modify HTTP and WebSockets messages that pass between your browser and web servers. When an intercepted message is being displayed, details of the destination server are shown at the top of the panel. For HTTP requests, you can manually edit the target server to which the request will be sent, by clicking on the server caption or the button next to it.
Forward- When you have reviewed and (if required) edited the message, click "Forward" to send the message on to the server or browser.
Drop- Use this to abandon the message so that it is not forwarded.
Interception is on/off - This button is used to toggle all interception on and off. If the button is showing "Intercept is on", then messages will be intercepted or automatically forwarded according to the configured options for interception of HTTP and WebSockets messages. If the button is showing "Intercept is off" then all messages will be automatically forwarded.
Action- This shows a menu of available actions that can be performed on the currently displayed message. These are the same options that appear on the context menu of the intercepted message display.
Comment field - This lets you add a comment to interesting items, to easily identify them later. Comments added in the intercept panel will appear in the relevant item in the Proxy history. Further, if you add a comment to an HTTP request, the comment will appear again if the corresponding response is also intercepted.
Highlight- This lets you apply a colored highlight to interesting items. As with comments, highlights will appear in the Proxy history and on intercepted responses.(Click image for large view)
2. History
The Proxy history maintains a full record of all messages that have passed through the Proxy. You can filter and annotate this information to help manage it. The Proxy history is always updated even when you have interception turned off, allowing you to browse without interruption while still monitoring key details about application traffic.
History Table
Separate history tables are shown for HTTP and WebSockets messages. Each table shows full details of the messages that have passed through the Proxy, and any modifications you have made to intercepted messages.
The HTTP history table contains the following columns:
- The request index number
- The protocol and server hostname
- The HTTP method
- The URL file path and query string
- Flag whether the request contains any parameters
- Flag whether the request or response were modified by the user
- The HTTP status code of the response
- The length of the response in bytes
- The MIME type of the response
- The URL file extension
- The page title (for HTML responses)
- Any user-applied comment
- Flag whether SSL is used
- The IP address of the destination server
- Any cookies that were set in the response
- The time the request was made
- The listener port on which the request was received
This tab contains Burp Proxy settings for Proxy listeners, intercepting HTTP requests and responses, intercepting WebSockets messages, response modification, match and replace, SSL pass through, and miscellaneous options.
A. 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. 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. Visit Configure Browser
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.
B. Intercepting HTTP Requests and Responses
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, status code, MIME type, HTML page title, and Proxy listener port. 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.
For requests, there is an option to automatically fix missing or superfluous new lines at the end of requests. If an edited request does not contain a blank line following the headers, Burp will add this. If an edited request with a body containing URL-encoded parameters contains any newline characters at the end of the body, Burp will remove these. This option can be useful to correct mistakes made while manually editing requests in the interception view, to avoid issuing invalid requests to the server.
C. 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. (There is a sub-option to prominently highlight unhidden fields on-screen, for easy identification.)
- Enable disabled form fields
- Remove input field length limits
- Remove JavaScript form validation
- Remove all JavaScript
- Remove
- Convert HTTPS links to HTTP
- Remove secure flag from cookies
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, for message headers and bodies, and also specifically for the first line only of requests. Each rule can specify a literal string or regex pattern to match, and a 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.
There are various default rules available to assist with common tasks - these are disabled by default.
E. 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 in requests - Some applications (often those using custom client components), compress the message body in requests. This option controls whether Burp Proxy automatically unpacks compressed request bodies. Note that some applications may break if they expect a compressed body and the compression has been removed by Burp.
- Unpack gzip / deflate in responses - Most browsers accept gzip- and deflate-compressed content in responses. This option controls whether Burp Proxy automatically unpacks compressed response bodies. Note that you can often prevent servers from attempting to compress responses by removing the Accept-Encoding header from requests (possibly using Burp Proxy's match and replace feature).
- 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.
- Disable logging to history and site map - This option prevents Burp from logging any requests to the Proxy history or the target site map. It may be useful if you are using Burp Proxy for some specific purpose, such as authenticating to upstream servers or performing match-and-replace operations, and you want to avoid incurring the memory and storage overhead that logging entails.
- Enable interception at startup - This option lets you configure whether Proxy interception should be enabled when Burp is started up. You can choose to always enable interception, always disable interception, or to restore the setting from when Burp was last closed.
Like it ? Share it.
