Burp Proxy 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, and also use the Proxy history to drive your testing workflow.

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

The WebSockets history table contains the following columns:

• The request index number
• The URL of the WebSockets connection
• The direction of the message (outgoing vs incoming)
• Flag whether the message was modified by the user
• The length of the response in bytes
• Any user-applied comment
• Flag whether SSL is used
• The time the message was received
• The listener port on which the message was received

You can reorder the table’s contents by clicking on any column header (clicking a header cycles through ascending sort, descending sort, and unsorted). For example, if you prefer your history table to grow “upwards”, with the most recent items at the top of the table, then you can apply a descending sort to the request number column.

You can also reorder the table’s columns by dragging columns. This can be useful if you want to ensure that certain columns are always visible.

If you select an item in the table, the lower pane shows the relevant message(s) for the item (whether HTTP or WebSockets messages). If a message was modified, either through user interception or through automatic response modification or match and replace rules, then each modified message is shown separately. The lower pane contains a message editor for each message, providing detailed analysis.

In addition to the main history view, you can also:

• Double-click an item in the table to show the item in a pop-up window.
• Use the context menu to open a new history window with its own display filter.

Proxy history display filter

Each history table has a display filter that can be used to hide some of its content from view, to make it easier to analyze and work on the content you are interested in.

The filter bar above the history table describes the current display filter. Clicking the filter bar opens the filter options for editing.

The HTTP history filter can be configured based on the following attributes:

• Request type - You can show only in-scope items, only items with responses, or only requests with parameters.
• MIME type - You can configure whether to show or hide responses containing various different MIME types, such as HTML, CSS, or images.
• Status code - You can configure whether to show or hide responses with various HTTP status codes.
• Professional Search term - You can filter on whether or not responses contain a specified search term. You can configure whether the search term is a literal string or a regular expression, and whether it is case sensitive. If you select the “Negative search” option, then only items not matching the search term will be shown.
• File extension - You can configure whether to show or hide items with specified file extensions.
• Annotation - You can configure whether to show only items with user-supplied comments or highlights.
• Listener - You can show only items received on a specific listener port. This can be useful when testing access controls.

The WebSockets history filter can be configured based on the following attributes:

• Request type - You can show only in-scope items (based on the URL of the WebSockets connection), or only incoming or outgoing messages.
• Professional Search term - You can filter on whether or not messages contain a specified search term. You can configure whether the search term is a literal string or a regular expression, and whether it is case sensitive. If you select the “Negative search” option, then only items not matching the search term will be shown.
• Annotation - You can configure whether to show only items with user-supplied comments or highlights.
• Listener - You can show only items received on a specific listener port. This can be useful when testing access controls.

The content displayed within the Proxy history is effectively a view into an underlying database, and the display filters control what is included in that view. If you set a filter to hide some items, these are not deleted, only hidden, and will reappear if you unset the relevant filter. This means you can use the filter to help you systematically examine a large Proxy history to understand where different kinds of interesting requests appear.

Proxy history annotations

You can annotate Proxy history items by adding comments and highlights. This can be useful to describe the purpose of different items, and to flag up interesting items for further investigation.

You can add highlights in two ways:

• You can highlight individual items using the drop-down menu on the left-most table column.
• You can highlight one or more selected items using the “Highlight” item on the context menu.

You can add comments in two ways:

• You can double-click the relevant entry, within the Comment column, to add or edit a comment in-place.
• You can comment one or more selected items using the “Add comment” item on the context menu.

You can also annotate items as they appear in the Intercept tab, and these will automatically appear in the history table.

When you have annotated interesting items, you can use column sorting and the display filter to quickly find these items later.

Proxy history testing workflow

As well as displaying details of all messages passing through the Proxy, the history enables you to control and initiate specific attacks, using the context menu. Depending on the type of history being shown, the options described below are available.

Add to / remove from scope

These options create new target scope rules which add or remove the selected item(s) from scope.

Scan / Spider / Send to …

You can send any item to other Burp tools, to perform further attacks or analysis. The ability to send requests between tools forms the core of Burp’s user-driven workflow.

Show response in browser

You can use this to render the selected response in your browser, to avoid the limitations of Burp’s built-in HTML renderer. When you select this option, Burp gives you a unique URL that you can paste into your browser (configured to use the current instance of Burp as its proxy), to render the response. The resulting browser request is served by Burp with the exact response that you selected (the request is not forwarded to the original web server), and yet the response is processed by the browser in the context of the originally requested URL. Hence, relative links within the response will be handled properly by your browser. As a result, your browser may make additional requests (for images, CSS, etc.) in the course of rendering the response - these will be handled by Burp in the usual way.

Request in browser

You can use this to re-issue the selected request in your browser (configured to use the current instance of Burp as its proxy). The following sub-options are available:

• In original session - This causes Burp to issue the request using the exact Cookie header that appeared in the original request.
• In current browser session - This causes Burp to issue the request using the cookies supplied by your browser. You can use this feature to facilitate testing of access controls, by selecting requests within Burp that were generated within one user context (e.g. an administrator), and reissuing the requests within a different user context that you are now logged in as (e.g. an ordinary user). When you are dealing with complex, multi-stage processes, this methodology, of manually pasting a series of URLs from Burp into your browser, is normally a lot easier than repeating a multi-stage process over and over, and modifying cookies manually using the Proxy.

Engagement tools

Professional This submenu contains various useful functions for carrying out engagement-related tasks:

• Find references - You can use the Find references function to search all of Burp's tools for HTTP responses that link to the selected item.
• Discover content - You can use the Discover content function to discover content and functionality that is not linked from visible content which you can browse to or spider.
• Schedule task - You can use the Schedule task function to create tasks that will run automatically at defined times and intervals.
• Generate CSRF PoC - You can use the Generate CSRF PoC function to create some HTML which, when viewed in a browser, will cause the selected request to be issued.

Show new history window

This creates a new window containing a new view of the Proxy history. In some situations, it can be useful to display more than one view into the underlying history data, and apply different filters to each view. For example, when testing access controls, you may log into an application in different user contexts, and want to review separately the different sequences of requests that occur in each user context. You can do this by using a separate browser for each user context you are testing, and create a separate Proxy listener for use by each browser (you will need to update your proxy configuration in each browser to point to the relevant listener). For each browser, you can then open a separate Proxy history window, and set the display filter to show only requests from the relevant Proxy listener port. As you use the application in each browser, each history window will show only the items for the associated user context. You can then use the “Request in browser in current browser session” function to switch requests between browsers, to determine how they are handled in that browser’s user context.

Add comment

You can use this function to add a comment to the selected item(s). See Annotations for more details.

Highlight

You can use this function to apply a highlight to the selected item(s). See Annotations for more details.

Delete item(s)

This function removes the selected item(s) permanently

Copy URL(s)

This function copies the URL(s) of the selected item(s) to the clipboard.

Copy as curl command

This function copies to the clipboard a curl command that can be used to generate the selected request.

Copy links

This function parses the selected item(s) for links, and copies these to the clipboard.

Save item(s)

This function lets you specify a file to save the details of selected item(s) in XML format, including full requests and responses, and all relevant metadata such as response length, HTTP status code and MIME type.