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.
Separate history tables are shown for HTTP and WebSocket 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 WebSockets history table contains the following columns:
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 WebSocket 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:
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:
The WebSockets history filter can be configured based on the following attributes:
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.
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 add comments in two ways:
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.
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.
These options create new target scope rules which add or remove the selected item(s) from scope.
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.
You can use this to render the selected response in Burp's 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 Burp's browser, 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 the browser. As a result, the 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.
You can use this to re-issue the selected request in Burp's browser. The following sub-options are available:
This submenu contains various useful functions for carrying out engagement-related tasks:
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.
You can use this function to add a comment to the selected item(s). See Annotations for more details.
You can use this function to apply a highlight to the selected item(s). See Annotations for more details.
This function removes the selected item(s) permanently
This function copies the URL(s) of the selected item(s) to the clipboard.
This function copies to the clipboard a curl command that can be used to generate the selected request.
This function parses the selected item(s) for links, and copies these to the clipboard.
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.