Last updated: July 20, 2021
Read time: 10 Minutes
Numerous options are available to configure the behavior of Burp Scanner during audit scans. These can be configured on-the-fly when launching a scan, or can be maintained in Burp's configuration library.
These settings let you tune the behavior of the audit logic to reflect the objectives of the audit and the nature of the target application.
The following options are available:
These settings control which issues Burp will check for.
You can select issue types individually, or according to the nature of the audit activity that is involved in detecting them. If you select individual issues, you can also select the detection methods that are used for some types of issues. Use the context menu on relevant issue types, and choose "Edit detection methods".
Each check that is performed increases the number of requests made, and the overall time of the audit. You can turn individual issues on or off based on your knowledge of an application's technologies. For example, if you know that an application does not use any LDAP, you can turn off LDAP injection. Or if you know which back-end database the application uses, you can turn off SQL injection detection methods that are specific to other database types.
Note: if any issues are enabled that are labeled "active", then Burp Scanner will send requests to the application designed to detect those issues. Depending on the issues selected, these requests might be reasonably viewed as malicious or might damage the application or its data.
These settings control how Burp Scanner handles application errors (connection failures and transmission timeouts) that arise during the audit phase of the scan.
You can configure the following options:
You can leave any setting blank to disable it.
These settings control how the Scanner places insertion points into each HTTP request that is audited.
Burp Scanner gives you fine-grained control over the placement of insertion points, and careful configuration of these options will let you tailor the audit to the nature of the application you are targeting. The configuration of insertion points also represents a trade-off between the speed and comprehensiveness of your scans.
The following categories of insertion point can be selected:
Note: As well as letting Burp automatically assign insertion points, it is possible to fully customize these, so you can specify arbitrary locations within a request where attacks should be placed. To use this function, send the request to Intruder, use the payload positions tab to define the start and end of each insertion point in the usual way, and select the Intruder menu option "Audit defined insertion points". You can also specify custom insertion point locations programmatically using Burp Extender.
These settings let you configure the Scanner to move parameters to other locations within the request, in addition to testing them in their original position. For example, you can move each URL parameter into the message body and retest it there. Or you can move each body parameter into a cookie and retest it there.
Moving parameters in this way can often bypass defensive filters. Many applications and application firewalls perform per-parameter input validation assuming that each parameter is in its expected location within the request. Moving the parameter to a different location can evade this validation. When the application code later retrieves the parameter to implement its main logic, it may do so using an API that is agnostic as to the parameter's location. If so, then moving the parameter may enable you to reach vulnerable code paths using input that would normally be filtered before being processed.
The following options are available for changing parameter locations:
Note that changing parameter locations results in many more scan requests, because each request parameter is effectively scanned multiple times.
These settings let you specify request parameters for which Burp Scanner should skip certain audit checks. There are separate lists for skipping server-side injection checks (such as SQL injection) and for skipping all checks.
Server-side injection checks are relatively time-consuming, because Burp sends multiple requests probing for various blind vulnerabilities on the server. If you believe that certain parameters appearing within requests are not vulnerable (for example, built-in parameters used only by the platform or web server), you can tell Burp not to test these. (Testing for client-side bugs like cross-site scripting involve much less overhead because testing each parameter imposes minimal overhead on the duration of the scan if the parameter is not vulnerable.)
Skipping all checks may be useful if a parameter is handled by an application component that you do not wish to test, or if modifying a parameter is known to cause application instability.
Each item in the list specifies the parameter type, the item to be matched (name or value), the match type (literal string or regex), and the expression to match.
You can identify parameters within URL path folders by their position (slash-delimited) within the URL path. To do this, select "URL path folder" from the parameter drop-down, "name" from the item drop-down, and specify the index number (1-based) of the position within the URL path that you wish to exclude from testing. You can also specify URL path folder parameters by value.
These settings let you configure whether Burp Scanner will avoid duplication in frequently occurring insertion points. If configured, Burp will identify insertion points that have proven to be uninteresting (occurring frequently without any issues generated) and will drop to performing a more lightweight audit of those insertion points.
You can select which insertion point types this optimization is applied to.
You can select whether to use nested insertion points. Nested insertion points are used when an insertion point's base value contains data in a recognized format. For example, a URL parameter might contain Base64-encoded data, and the decoded value might in turn contain JSON or XML data. With the option to use nested insertion points enabled, Burp will create suitable insertion points for each separate item of input at each level of nesting. Using this option imposes no overhead when scanning requests containing only conventional request parameters, but enables Burp to reach more of the attack surface of complex applications where data is encapsulated within different formats.
You can configure whether to set a limit on the number of insertion points that will be generated for each base request, thereby preventing your scans from becoming stalled if they encounter requests containing huge numbers of parameters. In cases where the number of insertion points is curtailed by this limit, the item's entry in the audit items view will indicate the number of insertion points that were skipped, enabling you to manually review the base request and decide if it is worth performing a full scan of all its possible insertion points.