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.
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.
- Search term - [Pro version]
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.
- Search term - [Pro version]
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.
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.
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 following options 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 - [Pro
version] This submenu contains various useful functions for
carrying out engagement-related tasks:
- Find references - [Pro
version] 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 - [Pro
version] 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 - [Pro
version] You can use
the Schedule task function to
create tasks that will run automatically at defined times and intervals.
- Generate CSRF PoC - [Pro
version] 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.