Burp Suite is an integrated platform for attacking web applications. It
contains a variety of tools
with numerous interfaces between them designed to facilitate and speed up the
process of attacking an application. All of the tools share the same robust framework
for handling and displaying HTTP messages, persistence, authentication, proxies, logging,
alerting and extensibility.
Burp Suite allows the individual tools to work together in highly
effective ways, for instance:
A central site map is used to aggregate information gathered about
target applications, and a centrally-defined target scope can be used to
control the behaviour of individual tools.
Any HTTP request and response processed by any of the Burp tools can be selected for treatment
by other tools. For example, a request from the Proxy history can be sent to
Intruder to form the basis of a custom automated attack, to Repeater for a manual attack,
to the Scanner for vulnerability analysis, or to Spider for automated
content discovery.
Applications can be "passively" spidered without generating huge numbers
of automated requests. All requests and responses passing through Burp Proxy
are parsed for links and forms, and the site map is updated accordingly,
allowing you to map sensitive applications in a non-intrusive manner, with
full control over every request that is made.
Requests passing through the Proxy can be automatically scanned for
security vulnerabilities while you are browsing (based
on the defined target scope).
The IBurpExtender interface can be used to extend
the functionality of Burp Suite and individual tools. Data processed by
one tool can be used in arbitrary ways to affect the behaviour and results
of other tools.
Burp Suite tools
Burp Suite contains the following tools:
Proxy - an intercepting HTTP/S proxy server which operates as a
man-in-the-middle between the end browser and the target web application,
allowing you to intercept, inspect and modify the raw traffic passing
in both directions.
Spider - an intelligent application-aware web spider which allows
complete enumeration of an application's content and functionality.
Scanner [Pro version
only] - an advanced tool for performing automated discovery of security
vulnerabilities in web applications.
Intruder - a highly configurable tool
for automating customised attacks against web applications, such as
enumerating identifiers, harvesting useful data, and fuzzing for common
vulnerabilities.
Repeater - a tool for manually manipulating and re-issuing
individual HTTP requests, and analysing the application's responses.
Sequencer - a tool for analysing the
quality of randomness in an application's session tokens or other important
data items which are intended to be unpredictable.
Decoder - a tool for performing manual
or intelligent decoding and encoding of application data.
Comparer - a utility for performing a
visual "diff" between any two items of data, normally pairs of related
requests and responses.
Use the above links to read the detailed help specific to each of the
individual Burp Suite tools. The remainder of this help describes some
typical usage scenarios for Burp Suite and the shared functionality and configuration options that affect the behaviour of all of the Burp tools.
Using Burp Suite
When Burp Suite is launched, Burp Proxy is started by default on port 8080 of
the local loopback interface. By setting a web browser to use this as its proxy
server, all web traffic can be intercepted, inspected and modified. By default,
requests for non-media resources are intercepted and displayed (this
default behaviour can be modified using options within Burp Proxy). All web traffic passing through
Burp Proxy is by default analysed and incorporated into the target
site map, to build up a picture of the content and functionality of the
applications visited. In Burp Suite Professional, all requests are by default
passively analysed by Burp Scanner to identify a range of security
vulnerabilities.
Before you begin work in earnest, you should ideally define the
target scope for your work. The easiest way to do this is to browse
to the application(s) you are targeting, then locate the relevant
hosts or directories within the site map, and use the context menus
to add URL paths to the scope. This central scope configuration can
be used to control the behaviour of the individual Burp tools in
various ways.
As you browse the target application, you can intercept requests
and responses in the Proxy for manual editing, or you can turn
interception off altogether. With interception off, a full history
is still maintained of each request and response, and content still
accumulates within the site map.
As well as modifying intercepted
messages within the Proxy, you can send these to other Burp tools to
perform various actions, for example:
You can send requests to Repeater, to manually fine tune an
attack against the application, and reissue an individual
request multiple times.
[Pro version
only] You can send requests to
Scanner, to perform active or passive vulnerability scanning.
You can send requests to Intruder, to launch a custom
automated attack to identify common vulnerabilities.
If you see a response containing a session token or other
identifier that it intended to be unpredictable, you can pass
this to Sequencer to test the randomness of the token.
Opaque data contained within any request or response can be
sent to Decoder to perform a smart decode and identify any
hidden information.
[Pro version
only] You can use various engagement tools to
make your work faster and more effective.
You can also perform any of the above actions on items in the proxy
history, on individual hosts, directories or files within the target
site map, or from anywhere within any of the tools where requests
and responses are displayed.
A central logging function can be used to record all requests and
responses made by individual tools, or the entire suite. The tools can run in a single tabbed window, or be detached in individual
windows. All tool and suite configuration is optionally persistent across
program loads. In Burp Suite Professional, you can save the entire state of the
component tools, to reload at a later stage and resume your work.
Burp menu
This menu contains a number of key functions and configuration options, which
are described below.
Search
[Pro version
only] Selecting "search" from the Burp menu opens a search dialog,
which is very easy to use. You can specify the following search
parameters:
the expression to search for
whether the search is case sensitive
whether the search is simple text or regular expression
whether the search is restricted to in-scope items only
whether the search results should dynamically update as new
HTTP messages are processed
which locations to search within HTTP messages (requests vs.
responses, headers vs. body)
which tools to search in
When you click "go", the search begins, and the key details of
each search match are shown in a sortable table, with a preview pane
where you can see the full request and response, including
highlighted matches for your search item. The usual context menus
can be used to initiate attacks against specific items, or send them
to other tools for further analysis:
Note that if you initiate a search via the context menu within the
target site map (as opposed to the Burp menu), then the search will
be specific to the selected branch(es) of the site map.
Saving and restoring state
[Pro version
only] The help
below describes the process of saving and restoring state, and some
common usage scenarios for this functionality.
Saving state
The items that can be saved include:
The target site map, which includes all of the content
discovered via the Proxy and Spider.
The Proxy history.
The issues identified by the Scanner.
The contents and histories of the Repeater tabs.
The configuration of all suite tools.
Selecting "save state" from the Burp menu launches a wizard where
you can define which items you want to save the state and
configuration of:
You then choose your output file, and Burp does the rest. You can
continue using Burp while its state is being saved - you may
experience some brief delays if you try to perform an operation on
data which Burp is in the process of saving, to prevent any data
corruption.
Obviously, because the save file includes the requests and responses
accumulated within the tools you are saving, this file can grow very
large. In practice, a few hours' testing will typically save or
restore in a minute or two. You can make this process leaner and
quicker by deleting unneeded items from the site map and proxy
history before performing a save.
Restoring state
Selecting "restore state" from the Burp menu launches a wizard
where you can define which items you want to restore the state and
configuration of. The first step is to select a file which you
previously saved. Burp then analyses this file to identify all of
its contents (remember that each save file can include the state and
configuration for any combinations of tools). For each type of saved
state and configuration, Burp lets you choose whether you want to
restore it, and if so whether to add to or replace the tool's
existing state:
Burp then goes to work and restores everything you have selected.
You can continue using Burp while its state is being restored - you
may experience some brief delays if you try to perform an operation
on data which Burp is in the process of restoring, to prevent any
data corruption.
Usage scenarios
The ability to save and restore tool state and configuration is
of huge benefit to penetration testers:
You can save your work at the end of each day and seamlessly
resume it the next morning.
You can back up key test information throughout a job, in
case of system crashes.
At the end of an engagement, you can store a full archive of
all accumulated information, enabling you to re-open your work
at a later point, to answer a client question or re-test a fixed
issue.
The task of mapping out an application's content can be
divided up between consultants, and the resulting site maps can
be merged incrementally into one, for all consultants to share.
Team leaders can optimise Burp's configuration for a
particular engagement, including fine-grained
target scope definition, and pass this configuration
straight to other team members to begin testing.
You can create configuration templates designed for
different kinds of task, save these for future use, and switch
between them easily.
Remembering settings
The "remember settings" options determine whether Burp Suite
will remember configuration settings across different loads of the software.
You can tell Burp to remember settings for all tools, or for
individually selected tools.
The "restore defaults" options reset all configuration settings
within Burp Suite or individual tools to their default values.
Lean mode
If this option is selected, then the next time Burp
Suite starts, it will run in a "lean" mode in which the only tools available
are Burp Proxy, Intruder and Repeater. Running in this mode creates a
smaller impact on system resources and is designed for users who prefer a
more simple lightweight tool.
Target site map
The central site map aggregates all of the information which Burp
has gathered about the application you are attacking. This includes
all of the resources which have been directly requested via the
Proxy, any items which have been inferred by analysing the responses
to those requests, and all content discovered using the Spider. When
you begin browsing a typical application, a large amount of content
will be mapped out for you before you even get as far as requesting
it, for example:
Items that have been requested are shown in black; those which
Burp has inferred but not yet requested are shown in grey. By
default, items that are typically uninteresting to penetration
testers are filtered from the display, but this behaviour can be
modified (described below).
The site map interface works essentially like a graphical email
client. A tree view of hosts and directories is shown on the left.
Selecting one or more nodes in the tree view causes all of the items
below these nodes to be shown in table form on the top right. This
table includes the key detail about each item (URL, status code,
page title, etc.) and allows the items to be sorted according to any
column (click any column heading to sort descending, or shift-click
to sort ascending). Selecting an item in the table causes the
request and response for that item to show in a preview pane on the
bottom right. This preview pane contains all of the functions
familiar from elsewhere in Burp - analysis of headers and
parameters, text search, media rendering, etc.
As well as displaying all of the information gathered about your
target, the site map enables you to control and initiate specific
attacks against it, using the context menus that appear everywhere.
For example, you can select a host or folder within the tree view,
and perform actions on the entire branch of the tree, such as
spidering or scanning:
Similarly, you can select an individual file within the tree or
table, and send the associated request to other tools, such as
Intruder or Repeater. If the item has not yet been requested by your
browser, Burp will construct a default request for the item, based
on the URL and any cookies received from the target domain:
[Pro version
only] You can use the context menu to access various
engagement tools, such as searching for
comments and scripts, analysing your target web site, scheduling
tasks, etc.
In the table view, you can annotate individual or multiple items,
by adding comments and highlights:
You can highlight individual items using a drop-down menu on the
left-most table column:
And you can comment individual items in-place by double-clicking
and editing the table cell:
Alternatively, if you want to annotate several items at once, you
select the relevant items and use the context menu to add comments
or apply highlights:
When you have annotated interesting requests, you can use column
sorting and display filters to quickly find these items later.
The content displayed within the site map is effectively a view
into an underlying database, and you can configure filters to
determine which items of underlying data are displayed within the
map. Some applications contain a large amount of content like
images, CSS, etc., which it is normally helpful to hide from view.
At the top of the site map, there is a filter bar. Clicking on this
shows a popup enabling you to configure exactly what content will be
displayed within the map:
You can choose to display only requests with parameters, or which
are within the current target scope. You can
filter by MIME type, HTTP status code and file extension. 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 complex site map to
understand where different kinds of interesting content reside.
[Pro version
only] You can also specify a search term to filter on, which will
only show items containing that expression in the request or
response, or within the user-added comment if applicable.
In addition to filtering content from view, you may sometimes
want to delete it altogether. For example, if you have browsed to
off-target domains, you will have accumulated data within Burp that
you just don't need. In this situation, you can permanently delete
the superfluous items using the context menus within the site map. For example, you can
select multiple hosts or folders within the tree or table views and
delete them altogether:
Target scope
The "scope" tab lets you tell Burp, at a Suite-wide level,
exactly what hosts and URLs constitute the target for your current
work. You can think of the target scope as, roughly, the items which
you are currently interested in and willing to attack.
The target scope can affect the behaviour of the individual Burp
tools in numerous ways, for example:
You can set display filters to show only in-scope items.
You can tell the Proxy to intercept only in-scope requests
and responses.
The Spider will only follow links that are in scope.
In Burp Suite Professional, you can automatically initiate
vulnerability scans of in-scope items.
You can configure Intruder and Repeater to follow redirects
to any in-scope URLs.
By telling Burp what your current target is, you can ensure that
Burp carries out numerous such actions in an appropriate way, only
going after items that you are interested in and willing to attack.
In all cases, you can additionally fine tune the target scope and
the associated behaviour at the level of individual tools, giving
you fine-grained control over everything that Burp does, if you need
it. However, the Suite-wide scope definition provides a quick and
easy way to tell Burp what is fair game and what is off limits, and
is almost always worth configuring before you begin your work in
earnest.
The configuration of target scope is very powerful, but also very
easy. The UI in the "scope" tab lets you define rules for what is
included within, or excluded from, the target scope. For each rule,
you can define the following fields:
Protocol - HTTP, HTTPS, or either.
Host - this can be either a regular expression to match the
hostname, or an IP range in various standard formats, for
example 10.1.1.1/24 or 10.1.1-20.1-127. If the host field is
left blank, then the rule can match requests to any host.
Port - this is a regular expression to match the port
number. If the port field is left blank, then the rule can match
requests to any port.
File - this is a regular expression to match the file
portion of the URL. If the file field is left blank, then the
rule can match requests for any file.
When Burp evaluates a URL to decide if it is within the target
scope, it will be deemed to be in scope if the URL matches at least
one "include" rule and does not match any "exclude" rules. This
enables you to define specific hosts and directories as being generally
within scope, and yet exclude from that scope specific
subdirectories or files. For example, the target scope defined below will match
any content within https://www.myapp.com and
https://staging.myapp.com with the exception of content below
https://www.myapp.com/admin and any URL containing the expression
"logout":
Configuring scope rules directly as described above is somewhat
unfriendly for many users. A much easier approach is to let Burp
define the rules for you based on intuitive instructions which you
give it using the context menus in the site map or elsewhere. Before
you begin testing the application, you simply need to browse to the
relevant content so that it appears in the site map. You can then
select one or more hosts and folders, and use the context menu to
include or exclude these from the scope. This process is extremely
easy and in most situations will let you quickly define all of the
rules necessary for your testing:
Suite options
The options tab contains Suite-wide settings which are not specific to any individual
tools.
These settings control the font which is used to display HTTP
messages, and whether syntax highlighting is performed for requests
and responses.
These settings determine timeouts for various network tasks. The "normal"
setting is used for most network communications, and determines how long Burp
Suite will wait before abandoning an
individual request and record that a timeout has occurred. The
"read until close" setting is only used where a response is being
processed which does not contain a Content-Length or Transfer-Encoding HTTP
header. In this situation, Burp Suite waits for the specified interval before
determining that the transmission has been completed. The "domain name
resolution" setting determines how often Burp Suite will re-perform successful
domain name look-ups. This should be set to a suitably low value if target host
addresses are frequently changing. The "failed domain name resolution" setting
determines how often Burp Suite will reattempt unsuccessful domain name
look-ups.
These settings control logging of network requests and responses. Logging can
be configured per-tool or for all Burp Suite traffic.
[Pro version
only] These settings let you configure Burp to save a backup of
all tools' state and configuration in the background at a configurable interval,
and also optionally on exit. This
setting persists across reloads of Burp. So you can configure Burp
to always save its state to a local temp directory, and know that
every time you use Burp you will have a backup copy of your work.
These settings control whether Burp Suite should perform authentication to
destination web servers. Different authentication types and credentials can be
configured for individual hosts. Supported types are: basic, NTLM and
digest authentication. The domain and hostname fields are only used for NTLM
authentication. The "prompt for credentials" option causes an interactive popup
to appear whenever an authentication failure is encountered.
These settings allow you to configure rules specifying different proxy settings
for different (ranges of) destination hosts.
The configuration shown above will make Burp talk directly to
staging.intranet.corp.com, use an internal proxy server without authentication
for everything else on *.intranet.corp.com, and use an authenticated gateway web
proxy for everything else, including the public internet.
You can use standard wildcards in the destination host specification. Rules are
applied in sequence, and the first rule which matches the web server you are
communicating with will be used. If no rule is matched, Burp defaults to direct,
non-proxy connections. For each upstream proxy you configure, you can specify an
authentication type and credentials if required. Supported types are: basic, NTLM and digest authentication. The
domain and hostname fields are only used for NTLM authentication.
This option enables you to configure a client SSL certificate (in PKCS12
format) which will be used whenever a destination HTTPS server requires client
certificate authentication.
Sometimes, you may have difficulty negotiating SSL connections
with certain web servers. The Java SSL stack contains a few
gremlins, and fails to work with certain unusual server
configurations. To help you troubleshoot this problem, Burp lets you
specify which protocols should be offered to servers during SSL
negotiations.
Note that Burp itself implements a few workarounds for SSL issues,
and if a negotiation fails with the protocols you have configured,
Burp will still try some alternative combinations of protocols which
often work. So you shouldn't use this feature as a method of testing
which protocols are actually supported by the server.
This information-only panel contains details of all X509 certificates
received from destination web servers. Double-click an item in the table to display
the full details of the certificate.
[Pro version
only] You can use the task scheduler to automatically start and stop
certain tasks at defined times and intervals. For example, the
configuration shown above will begin scanning a target overnight at
2am, and suspend the scanner each day during working hours.
You can create tasks via the context menus which appear
throughout Burp, or using the "new task" button in the above panel.
This action starts a wizard which lets you configure the details and
timing of the task. Various different types of task are available:
You can configure each task to be one-off, or to repeat at
regular intervals.
These settings enable you to specify
hostname-to-IP mappings which override the DNS resolution provided
by the operating system. This feature can be used to ensure correct
onward forwarding of requests when the hosts file has been modified
to perform invisible proxying of traffic from non-proxy-aware thick
client components.
Any location where HTTP responses are displayed within Burp Suite it is
possible to render HTML content as it would appear within your browser. This
option controls whether Burp Suite will make any additional HTTP requests that
are required to fully render HTML content (for example, for embedded images).
Use of this option involves a trade-off between the speed and the quality of
HTML rendering performed by Burp Suite.
These options control the handling of HTTP 100 Continue responses from
servers. These often occur when a POST request is sent to the server, and it
makes an interim response before the request body has been transmitted. If
"understand 100 Continue responses" is checked, Burp Suite will skip the interim
response and parse the real response headers for response information like
status code and content type. If "remove 100 Continue headers" is checked,
Burp Suite will remove any interim headers from the server's response before this is
passed to individual tools.
Engagement tools
[Pro version
only] A number of tools exist to help make your work faster and more
effective. These can be accessed via the context menus which appear
throughout Burp:
Note that if you initiate a search from within the target site
map (as opposed to the Burp menu), then the search will be specific
to the selected branch(es) of the site map.
Find comments and scripts
You can use these functions to search part or all of the site map
for scripts and comments. The search results window shows responses
from all Burp tools containing either scripts or comments. Selecting
an individual item shows the full request and response in a preview
pane, with relevant items automatically highlighted, and also
extracted into their own tab:
You can use the "export" button to save all of the scripts or
comments to file or to the clipboard, optionally consolidating
duplicated items.
Find references
Anywhere you see an HTTP request, URL, domain, etc., you can use
the "find references" function to search all of Burp's tools for
HTTP responses which link to that item. The search results window
shows responses from all Burp tools which link to the selected item.
When you view an individual search result, the response is
automatically highlighted to show where the linking reference
occurs:
Note that this feature treats the original URL as a prefix
when searching for links, so if you select a host, you will find all
references to that host; if you select a folder, you will find all
references to items within that folder or deeper.
The new "find references" feature effectively serves the same
purpose as the "linked from" list that existed in earlier versions
of Burp Spider, but is much more powerful.
Analyse target
This function can be used to analyse a target web application and
tell you how many static and dynamic URLs it contains, and how many
parameters each URL takes. This can help you assess how much effort
a penetration testing engagement is likely to involve, and can help
you decide where to focus your attention during the test itself.
To access this feature, select one or more hosts or branches within
the site map, and launch it using the context menu. The summarised
information looks like this:
And you can drill down into more detail about individual URLs:
You can also export all of this information as an HTML report,
which you can attach to client proposals and reports to show the
attack surface you have covered.
Note: (i) This function only
analyses the content already captured within the site map, so you
should ensure that you have fully browsed or spidered all of the
application's content and functionality before running it. (ii) URLs
are deemed to be "static" if they no not take any parameters in the
URL or message body; however the responses from these URLs may still
be dynamically generated by the application.
Discover content
You can use this function to discover content and functionality
which is not linked from visible content which you can browse to or
spider.
Burp uses various techniques to discover content, including name
guessing, web spidering, and extrapolation from naming conventions
observed in use within the application. The feature is highly
configurable, as shown by the available options which are explained
below:
Target - These options control which directory to begin
discovery from. Only items within this path and its subdirectories
will be requested during the session. You can choose to discover
files or directories or both, and how deep to recurse into
discovered subdirectories.
Test case generation - These options control which file and
directory names Burp will use when making requests to discover
content. As well as built-in lists, Burp can harvest names used
elsewhere within an application, and retry them at other locations,
and can construct names based on discovered items, for example by
cycling values in filenames containing numbers.
File extensions - You can specify a list of file extensions
with which to test each possible filename. Burp can harvest file
extensions observed in use within the application, and test these
with every filename. When a file has been confirmed, Burp can also
try a specific list of variant extensions with that filename, for
example to check for old or backup versions of the same file.
Discovery engine - You can control how many threads are used
for content discovery and spidering, whether file names are handled
case sensitively, and how the discovery session interacts with
Burp's main site map (in the target tab of the suite).
When you have configured your discovery session, you can start it
from the control tab, which also provides runtime information about
the actions being performed. The work is divided into numerous
discrete tasks, which are prioritised according to their likelihood
of quickly discovering new content, and new tasks are generated
recursively as content is confirmed:
The discovery session employs its own site map, showing all of
the content which has been discovered within the defined scope. If
you have configured Burp to do so, newly discovered items will also
be added to Burp's main site map.
This feature won't exactly enhance your productivity, but you may
sometimes find it useful nonetheless. You can use it to make Burp
simulate manual testing activities, by sending common test payloads
to random URLs and parameters within a target application, at
irregular intervals. Burp doesn't do anything with the responses, so
you won't find out about any bugs in this way. But if you think that
someone might be reviewing the application's logs to confirm that
you are working, you can use this feature while you nip out for a
long lunch, gym session, drinking binge, or whatever happens to be
your preferred diversion.
Easter Eggs, anyone?
Message editor
Throughout Burp, a custom text editor is used which is optimised
for viewing and editing HTTP requests and responses. Request and
response syntax is automatically colourised to highlight interesting
items. Mouse-over pop-ups perform automatic URL decoding (for
requests) and HTML decoding (for responses).
The following shortcut keys are available:
Ctrl + A, select all
Ctrl + X, cut selected text
Ctrl + C, copy selected text
Ctrl + V, paste
Ctrl + F, find and highlight the selected text throughout
the message
Ctrl + Z, undo last edit
Ctrl + Y, redo last undone edit
Ctrl + U, URL-encode selected text (hold down Shift to
decode)
Ctrl + H, HTML-encode selected text (hold down Shift to
decode)
Ctrl + B, Base64-encode selected text (hold down Shift to
decode)
Ctrl + left, move to previous word
Ctrl + right, move to next word
Ctrl + up, move to previous paragraph
Ctrl + down, move to next paragraph
Ctrl + home, go to start of message
Ctrl + end, go to end of message
Ctrl + backspace, delete previous word
Ctrl + del, delete next word
Right-clicking on any request or response produces a context menu that can be
used to perform various actions:
send to - You can send any message, or a selected portion of the
message, to other tools within Burp Suite, to perform further attacks or
analysis.
find references - [Pro version
only] You can use this
function to search all of Burp's tools for HTTP responses which link to
the selected item.
discover content - [Pro version
only] You can use this
function to discover content and functionality which is not linked from
visible content which you can browse to or spider.
schedule task - [Pro version
only] You can use this
function to create tasks which will run automatically at defined times
and intervals.
change request method - For requests, you can automatically switch the
request method between GET and POST, with all relevant request parameters
suitably relocated within the request. This option can be used to quickly
test the application's tolerance of parameter location in potentially
malicious requests (e.g. cross-site scripting).
change body encoding - For requests, you can switch the encoding
of any message body between application/x-www-form-urlencoded and
multipart/form-data.
copy URL - This function copies the full current URL to the
clipboard.
copy to file - This function allows you to select a file and copy
the contents of the message to the file. This is handy for binary content,
when copying via the clipboard may cause problems. Copying operates on the
selected text or, if nothing is selected, the whole message.
paste from file - This function allows you to select a file and
paste the contents of the file into the message. This is handy for binary
content, when pasting via the clipboard may cause problems. Pasting replaces
the selected text or, if nothing is selected, inserts at the cursor
position.
save item - This function lets you specify a file to save the
selected request and response in XML format, including all relevant metadata
such as response length, HTTP status code and MIME type.
convert selection - These functions enable you to perform quick
encoding or decoding of the selected text in a variety of schemes.
URL-encode as you type - If this option is turned on then
characters like & and = will be automatically replaced with their
URL-encoded equivalents as you type.
Extensibility
Burp Suite is extensible via the
IBurpExtender and other interfaces, which are defined below:
IBurpExtender allows third-party developers to extend the
functionality of Burp Suite by creating partial or full implementations of the
interface which will be dynamically loaded and executed by Burp
Suite on startup. Implementations can perform various actions,
including carrying out custom processing on HTTP requests and
responses passing through Burp Proxy.
IBurpExtenderCallbacks defines a range of methods which can be
used by IBurpExtender impementations to perform actions within Burp
Suite. On startup, Burp Suite passes to the IBurpExtender
implementation a reference to an instance of IBurpExtenderCallbacks.
Available actions include:
Issuing arbitrary HTTP requests and retrieving responses.
Sending requests to Burp tools, including Repeater,
Intruder, Spider and Scanner.
Querying and updating the Suite-wide target scope.
Issuing alerts via the Burp Suite alerts tab.
The IHttpRequestResponse, IScanIssue and IScanQueueItem
interfaces provide methods to access details of HTTP messages, scan
issues and items in the active scan queue.
The functionality exposed by these interfaces enables developers to build highly
functional extensions to Burp Suite. For example, a common problem when
attacking some web applications is that the application aggressively validates
user-submitted data and terminates the user's session whenever a potentially
malicious request is received. This can considerably slow down an attack as the
user is required to manually log in repeatedly. This problem can be mitigated by
writing a small extension to Burp Suite which monitors server responses to
identify those which are redirects to the login page. When such a response is
identified, the extension initiates a new application login, obtains a fresh
session token, and injects a Set-Cookie header into the intercepted response to
ensure that the client session is seamlessly restored.
Copyright (c) 2010 PortSwigger Ltd. All rights reserved. Email us.
