PROFESSIONAL

Burp Intruder options

  • Last updated: January 27, 2023

  • Read time: 6 Minutes

You can edit Burp Intruder settings before you launch an attack under Options in the attack tab. You can modify many of the settings while the attack is running. Edit these in the cloned Options tab in the results window.

Save options

By default, attacks are saved in-memory, so they are lost if you close Burp Suite. However, you can save them to your project file. Select Save attack to project file.

We recommend you only save attacks when you find something interesting. If you save too many attacks to project files it can result in large files.

Request headers

These settings control whether Intruder updates the configured request headers during attacks:

  • Update Content-Length header - Add or update the Content-Length header in each request with the correct length of the request's HTTP body. This is useful for attacks that insert variable-length payloads into the body of the template HTTP request. If the correct length is not specified, then the target server may return an error, respond to an incomplete request, or wait indefinitely for further data to be received in the request.
  • Set Connection header - Add or update the Connection header with the value close. This may mean attacks are performed more quickly when the server does not itself return a valid Content-Length or Transfer-Encoding header.

Error handling

These settings control how Intruder handles network errors during an attack:

  • Number of retries on network failure - Specify the number of times Burp retries a request when a failure occurs. Intermittent network failures are common when testing, so it is best to retry the request several times.
  • Pause before retry - Specify the time (in milliseconds) that Burp waits before retrying a failed request. If the server is being overwhelmed with traffic, or an intermittent problem is occurring, it is best to wait a short time before retrying.

Attack results

These settings control what information is captured in the attack results:

  • Store requests / responses - Specify whether the attack saves the contents of individual requests and responses. This consumes disk space in your temporary directory, but enables you to:

    • View requests and responses in full during an attack.
    • Repeat individual requests if necessary.
    • Send requests or responses to other Burp tools.
  • Make unmodified baseline request - Set the attack to issue the template request with all payload positions set to their base values, in addition to the configured attack requests. The request shows as item 0 in the results table. This is useful to provide a base response against which to compare the attack responses.
  • Use denial-of-service mode - Set the attack to not process any responses received from the server. As soon as each request is issued, the TCP connection is closed. This is useful for application-layer denial-of-service attacks against vulnerable applications, as it repeatedly sends requests that initiate high-workload tasks on the server, while avoiding locking up local resources by holding sockets open for the server to respond.
  • Store full payloads - Store the full payload values for each result. This consumes additional memory but may be required to perform certain actions at runtime, such as modifying payload grep settings, or resending requests with a modified request template.

Grep - match

These settings flag result items that contain specified expressions in the response.

  • Flag result items with responses matching these expressions - Specify a list of expressions to flag. By default, the expressions list shows some common error strings that are useful when fuzzing.
  • Match type - Specify whether the expressions are simple strings or regular expressions.
  • Case sensitive match - Specify whether the check for the expression is case-sensitive.
  • Exclude HTTP headers - Specify whether the HTTP response headers are excluded from the check.

During the attack, Burp adds a results column for each expression in the list. This records the number of times the expression is found in the response. To identify results with the expression, click on the column header to sort the results.

Intruder grep match

Related pages

You can use this option to quickly identify interesting items from large sets of results. For more information, and some common use cases, see:

Grep - extract

These settings extract information from responses.

To specify an interesting string for information extraction, select Extract the following items from responses, and click Add. A new window opens in which you can define the location of the item to be extracted.

Confirming the selection

Note

To extract information from multiple occurrences of an item, add the item multiple times in succession. This is useful, for example, when an HTML table contains useful information but there are no unique prefixes with which to automatically pick out each item.

To configure a maximum length that Burp captures for each item, enter a value in the Maximum capture length field.

During the attack, Burp adds a results column for the extracted information. Click the column header to sort the results.

Extract grep results

Related pages

  • For more information on how to configure the details of items to extract, see Response extraction rules.
  • You can use this option to mine data from an application. For more information and some common use cases, see Harvesting useful data.

Grep - payloads

These settings can be used to flag result items containing reflections of the submitted payload:

  • Case sensitive match - Specify whether the check for the payload is case-sensitive.
  • Exclude HTTP headers - Specify whether the HTTP response headers should be excluded from the check.
  • Match against pre-URL-encoded payloads - Check responses for payloads in their pre-encoded form. This may be necessary if you have configured Intruder to URL-encode payloads within requests. These are normally decoded by the application and echoed in their original form.

During the attack, Burp adds a results column that records the number of times the payload is found in the response. If more than one payload set is used, a separate column is added for each payload set.

You can use this option to detect cross-site scripting and other response injection vulnerabilities, which can arise when user input is dynamically inserted into the application's response.

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.

Note

Automatically following redirections may sometimes cause problems for your attack. For example, if the application responds to a malicious request with a redirection to the logout page, then your session may be terminated.

The following options are available:

  • Follow redirections - Control the targets of redirections. You can choose from:

    • Never.
    • On-site only.
    • In-scope only.
    • Always.
  • Process cookies in redirections - Resubmit any cookies set in the redirection response when the redirection target is followed. This may be necessary, for example, 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 follows up to 10 chained redirections. A column in the results table indicates whether a redirect was followed for each individual result. The full requests and responses in the redirection chain are stored with each result item.

You can configure the types of redirection that Burp processes in the suite-wide redirection options. For more information, see Options: HTTP.

Note

It may be necessary to use only a single-threaded attack when following redirections. For example, when the application stores the result of the initial request within your session, and retrieves this when delivering the redirection response.

Was this article helpful?