Burp Intruder attack settings

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

Save attack

Professional 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 that 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.

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.

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.

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 the Grep - payloads settings 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.

The following settings 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 settings. These are found under Proxy in the Settings dialog. Click on Settings to open the dialog. For more information, see HTTP Settings.

HTTP version

Use this setting to control whether Burp Intruder uses HTTP/2 or HTTP/1 for the current attack.

If you enable Override the project-level HTTP/2 setting, then Burp ignores the current project-level HTTP/2 setting configuration.

You can then choose whether to use HTTP/2 or HTTP/1 for the current attack. Select Default to HTTP/2 if the server supports it to use HTTP/2 with all servers that advertise support for it during the TLS handshake. Deselect this option to use HTTP/1 even if the server supports HTTP/2.