Attack Options
This tab contains Intruder attack options for request
headers, the request engine,
attack results, grep match,
grep extract, grep
payloads, and redirections. You can edit these
options in the main Intruder UI before launching an attack, and most
settings can also be modified in the
attack window when the attack is already running.
Request Headers
These settings control whether Intruder updates the
configured request headers during attacks. Note that you have full control
over the request headers via the request template in
the
payload positions tab. These options can
be used to update those headers per-request in ways that are normally
helpful.
The following options are available:
- Update Content-Length header - This option causes Intruder
to add or update the Content-Length header in each request,
with the correct value for the length of the HTTP body of that particular request.
This feature is usually essential for attacks that insert variable-length payloads
into the body of the template HTTP request. If the correct value is not specified,
then the target server may return an error, may respond to an incomplete request,
or may wait indefinitely for further data to be received in the request.
- Set Connection: close - This option causes Intruder
to add or update the Connection header with the value "close". In some cases (when the server does not itself
return a valid Content-Length or Transfer-Encoding header), this option may
allow attacks to be performed more quickly.
Request Engine
These settings control the engine used for making HTTP requests in the
Intruder attack. The following options are available:
- Number of threads - [Pro
version] This option controls the number of concurrent requests
the attack is able to make.
- Number of retries on network failure - If a
connection error or other network problem occurs, Burp will retry the
request the specified number of times before giving up and moving on.
Intermittent network failures are common when testing, so it is best to
retry the request several times when a failure occurs.
- Pause before retry - When retrying a failed
request, Burp will wait the specified time (in milliseconds) following
the failure before retrying. If the server is being overwhelmed with
traffic, or an intermittent problem is occurring, it is best to wait a
short time before retrying.
- Throttle between requests - Optionally, Burp can
wait a specified delay (in milliseconds) before every request. This
option is useful to avoid overloading the application, or to be more
stealthy. Alternatively, you can configure a variable delay (with a
given start value and increment). This option can be useful to test the
session timeout interval enforced by the application.
- Start time - This
option lets you configure the attack to start immediately, or after a
specified delay, or to start in a paused state. These alternatives can
be useful if an attack is being configured which will be executed at
some future point, or saved for future use.
Careful use of these options lets you fine tune the attack engine, depending on the performance
impact on the application, and on your own processing power and bandwidth. If
you find that the attack is running slowly, but the application is performing
well and your own CPU utilization is low, you can increase the number of threads to make your
attack proceed faster. If you find that connection errors
are occurring, that the application is slowing down, or that your own computer
is locking up, you should reduce the thread count, and maybe increase the number
of retries on network failure and the pause between retries.
Attack Results
These settings control what information is captured in the
attack
results. The following options are available:
- Store requests / responses - These options
determine whether the attack will save the contents of individual
requests and responses. Saving requests and responses consumes disk
space in your temporary directory, but enables you to view these in full
during an attack, repeat individual requests if necessary, and send them
to other Burp tools.
- Make unmodified baseline request - If this option
is selected, then in addition to the configured attack requests, Burp
will issue the template request with all payload positions set to their
base values. This request will show as item #0 in the results table.
Using this option is useful to provide a base response against which to
compare the attack responses.
- Use denial-of-service mode - If this option is
selected, then the attack will issue requests as normal but will not
wait to process any responses received from the server. As soon as each
request is issued, the TCP connection will be closed. This function can
be used to perform application-layer denial-of-service attacks against
vulnerable applications, by repeatedly sending requests that initiate
high-workload tasks on the server, while avoiding locking up local
resources by holding sockets open waiting for the server to respond.
- Store full payloads - If this option is selected,
Burp will store the full payload values for each result. This option
consumes additional memory but may be required if you want to perform
certain actions at runtime, such as modifying payload grep settings, or
reissuing requests with a modified request template.
Grep - Match
These settings can be used to flag result items containing specified
expressions in the response. For each item configured in the list, Burp will
add a new results column containing a checkbox indicating whether the item
was found in each response. You can then sort on this column (by clicking
the column header) to group the matched results together.
Using this option can be very powerful in helping to analyze large sets
of results, and quickly identifying interesting items. For example, in
password guessing attacks, scanning for phrases such as "password incorrect"
or "login successful" can locate successful logins; in testing for SQL
injection vulnerabilities, scanning for messages containing "ODBC", "error",
etc. can identify vulnerable parameters.
In addition to the list of expressions to match, the following options
are available:
- Match type - This specifies whether the expressions
are simple strings or regular expressions.
- Case sensitive match - This specifies whether the
check for the expression should be case sensitive.
- Exclude HTTP headers - This specifies whether the
HTTP response headers should be excluded from the check.
Grep - Extract
These settings can be used to extract useful information from responses
into the attack results table. For each item configured in the list, Burp
will add a new results column containing the text that was extracted for
that item. You can then sort on this column (by clicking the column header)
to order the extracted data.
This option is useful for mining data from the application and can
support a wide range of attacks. For example, if you are cycling through a
range of document IDs, you can extract the page title of each document
looking for interesting items. If you have found a function that returns
details of other application users, you can iterate through user IDs and
retrieve relevant fields about users looking for administrative accounts or
even passwords. If a "forgotten password" function takes a username as a
parameter and returns a user-configured password hint, you can run through a
list of common usernames and harvest all the associated password hints, and
then visually scan through the list looking for easily guessed passwords.
If the same matching item is added multiple times in succession, then
each server response will be searched for multiple occurrences of that expression,
and the text immediately following each occurrence will be captured. This can
be useful, for example when an HTML table contains useful information but there are
no unique prefixes with which to automatically pick out each item.
For details of configuring the details of items to extract, see the help
on using the
response extraction
rule dialog.
Optionally, you can configure a maximum length that Burp should capture
for each item.
Grep - Payloads
These settings can be used to flag result items containing reflections of
the submitted payload. If the option is enabled, Burp will add a new results
column containing a checkbox indicating whether the value of the current
payload was found in each response. (If more than one
payload set is used, a separate column will be added for each payload set.)
This
feature can be useful in detecting cross-site scripting and other response injection
vulnerabilities, which can arise when user input is dynamically inserted into
the application's response.
The following options are available:
- Case sensitive match - This specifies whether the
check for the payload should be case sensitive.
- Exclude HTTP headers - This specifies whether the
HTTP response headers should be excluded from the check.
- Match against pre-URL-encoded payloads - It is
normal to configure Intruder to
URL-encode
payloads within requests. However, these are normally decoded by the
application and echoed in their original form. You can use this option
to make Burp check responses for payloads in their pre-encoded form.
Redirections
These settings control how Burp handles redirections when performing
attacks. It is often necessary to follow redirections to achieve the
objectives of your attack. For example, in a password guessing attack, the
result of each attempt might only be displayed by following a redirection.
When fuzzing, relevant feedback might only appear in an error message that
is returned after an initial redirection response.
The following options are available:
- Follow redirections - This setting controls the
targets of redirections that are followed. The following options are
available:
- Never - Intruder will not follow any redirections.
- On-site only - Intruder will only follow redirections to the same web "site",
i.e. to URLs employing the same host, port and protocol as was used in the
original request.
- In-scope only - Intruder will only follow
redirections to URLs that are within the suite-wide
target scope.
- Always - Intruder will follow redirections to any URL whatsoever. You should
use this option with caution - occasionally, web applications relay your
request parameters in redirections to third-parties, and by following
redirections you may inadvertently attack an application that you do not intend
to.
- Process cookies in redirections - If this option is
selected, then any cookies set in the redirection response will be
resubmitted when the redirection target is followed. For example, this
option may be necessary if you are attempting to brute force a login
challenge that always returns a redirection to a page indicating the
login result, and a new session is created in response to each login
attempt.
Burp will follow up to 10 chained redirections if necessary. A column in
the results table will indicate whether a redirect was followed for each
individual result, and the full requests and responses in the redirection
chain are stored with each result item. The types of redirection that Burp
will process (3xx status code, Refresh header, etc.) are configured in the
suite-wide redirection options.
Some further points are worth noting in relation to redirections:
- In some situations it may be necessary to use only a single-threaded
attack when following redirections. This arises when the application stores
the result of the initial request within your session, and retrieves
this when delivering the redirection response.
- Automatically following redirections may
sometimes cause problems for your attack - for example, if the application responds
to some malicious requests with a redirection to the logout page, then following
redirections may result in your session being terminated when it would not otherwise
do so.