Burp Scanner Options
Attack Insertion Points
These settings control how the Scanner places "insertion points" into each base request that is sent for active scanning. An insertion point is a location within the request where attacks will be placed, to probe for vulnerabilities. Each defined insertion point is scanned individually.
Burp gives you fine-grained control over the placement of insertion points, and careful configuration of these options will let you tailor your scanning 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.
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 base 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 "Actively scan defined insertion points". You can also specify custom insertion point locations programmatically using Burp Extender.
Insertion Point Locations
These settings let you select the types of locations within the request where insertion points should be placed:
- URL parameter values - Standard parameter values within the URL query string.
- Body parameter values - Parameter values in the message body, including standard form-generated parameters, attributes of multipart-encoded parameters such as uploaded file names, XML parameter values and attributes, and JSON values.
- Cookie parameter values - The values of HTTP cookies.
- Parameter name - The name of an arbitrarily added parameter. A URL parameter is always added, and a body parameter is also added to POST requests. Testing an added parameter name can often detect unusual bugs that are missed if only parameter values are tested.
- HTTP headers - The values of the Referer and User-Agent headers. Testing these insertion points can often detect issues like SQL injection or persistent XSS within logging functionality.
- Entire body (for relevant content types) - The whole of the request body. This applies to requests with XML or JSON content in the request body.
AMF string parameters (use with caution) - The values of any string
data within AMF-encoded messages.
Note: Burp uses a third-party library for parsing AMF messages. Historically, there have been security vulnerabilities in this library's processing of malicious AMF messages. It is recommended that you do not enable this option when accessing any untrusted application functionality or content.
- URL path filename - The value of the filename part of the URL path (after the final path folder and before the query string).
- URL path folders - The values of all folder tokens within the URL path (before the filename part). Testing each of these insertion points can impose a significant overhead and should only be used if you believe the application is using these locations to transmit parameter data.
Change Parameter Locations
These settings let you configure the Scanner to move some types of insertion point 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:
- URL to body
- URL to cookie
- Body to URL
- Body to cookie
- Cookie to URL
- Cookie to body
Note that changing parameter locations results in many more scan requests, because each request parameter is effectively scanned multiple times.
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.
Maximum Insertion Points Per Request
Whatever settings you select, the number of insertion points for an individual request will generally depend on features of that request, such as the number of parameters. Occasionally, requests may contain an excessive number of parameters (hundreds, or more). If Burp performed a full scan of every parameter, the scan would take an excessive amount of time to complete.
This setting lets you 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 active scan queue 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.
These settings let you specify request parameters for which Burp should skip certain tests. There are separate lists for skipping server-side injection tests (such as SQL injection) and for skipping all checks.
Server-side injection tests 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 tests 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.
Active Scanning Engine
These settings control the engine used for making HTTP requests when doing active scanning. The following options are available:
- Number of threads - This option controls the number of concurrent requests the Scanner 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.
- Add random variations to throttle - This option can further increase stealth by reducing patterns in the timing of your requests.
- Follow redirections where necessary - Some vulnerabilities can only be detected by following redirections (for example, cross-site scripting in an error message which is only returned after following a redirection). Because some applications issue redirections to third-party URLs that include parameter values that you have submitted, Burp protects you against inadvertently attacking third-party applications, by not following just any redirection which is received. If the request being scanned is within the defined target scope (i.e. you are using target scope to control what gets scanned), then Burp will only follow redirections that are within that same scope. If the request being scanned is not in scope (i.e. you have manually initiated a scan of an out-of-scope request), Burp will only follow redirections which (a) are to the same host/port as the request being scanned; and (b) are not explicitly covered by a scope exclusion rule (e.g. "logout.aspx").
Careful use of these options lets you fine tune the scanning engine, depending on the performance impact on the application, and on your own processing power and bandwidth. If you find that the Scanner 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 scans 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. If the functionality of the application is such that actions performed on one base request interfere with the responses returned from other requests, you should consider reducing the thread count to 1, to ensure that only a single base request is scanned at a time.
Active Scanning Optimization
These options let you tune the behavior of the active scanning logic to reflect the objectives of the scan and the nature of the target application. For example, you can choose to quickly scan for more easily discovered issues in a large application; or you can perform a much slower comprehensive scan to discover issues that are harder, and require many more scan requests, to detect.
The following options are available:
- Scan speed - This option determines how thorough certain scan checks will be when checking for vulnerabilities. The "Fast" setting makes fewer requests, and checks for fewer derivations of some vulnerabilities. The "Thorough" setting makes many more requests and checks for more derivative types of vulnerabilities. The "Normal" setting is mid-way between the two, and represents a suitable trade-off between speed and thoroughness for many applications.
- Scan accuracy - This option determines the amount of evidence that the Scanner will require before reporting certain types of vulnerabilities. Some issues can only be detected using "blind" techniques, in which Burp infers the probable existence of a vulnerability based on some observed behavior, such as a time delay or a differential response. Because these observed behaviors can occur anyway, in the absence of the associated vulnerability, the techniques are inherently more prone to false positives than other techniques, such as the observation of error messages. To attempt to reduce false positives, Burp repeats certain tests a number of times when a putative issue is inferred, to try and establish a reliable correlation between submitted inputs and observed behaviors. The accuracy option is used to control how many times Burp will retry these tests. The "Minimize false negatives" setting performs fewer retries, and so is more likely to report false positive issues, but is also less likely to miss genuine issues due to inconsistent application behavior. The "Minimize false positives" setting performs many more retries, and so is less likely to report false positive issues, but may as a result wrongly miss some genuine issues, because some of the retry requests might just happen to fail to return the result being tested for. The "Normal" setting is mid-way between the two, and represents a suitable trade-off between false positive and false negative issues for many applications.
- Use intelligent attack selection - This option makes scans more efficient by omitting checks that appear irrelevant given the base value of the parameter at each insertion point. For example, if a parameter's value contains characters that do not normally appear in filenames, Burp will skip file path traversal checks for this parameter. Using this option can speed up your scans, with a relatively low risk of missing actual vulnerabilities that exist.
Active Scanning Areas
These options let you define which checks are performed during active scanning. The following categories of checks are available:
- SQL injection - This has sub-options to enable different testing techniques (error-based, time-delay tests, and Boolean condition tests), and also to enable checks that are specific to individual database types (MSSQL, Oracle, and MySQL).
- OS command injection - This has sub-options to enable different testing techniques (informed and blind).
- Server-side code injection
- Server-side template injection
- Reflected cross-site scripting
- Stored cross-site scripting
- Reflected DOM issues
- Stored DOM issues
- File path traversal / manipulation
- External / out-of-band interaction
- HTTP header injection
- SMTP header injection
- XML / SOAP injection
- LDAP injection
- Cross-site request forgery
- Open redirection
- Header manipulation
- Server-level issues
- Suspicious input transformation
- Input returned in response (reflected)
- Input returned in response (stored)
Each check that is performed increases the number of requests made, and the overall time of each scan. You can turn individual checks 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 tests. Of if you know which back-end database the application uses, you can turn off SQL injection checks that are specific to other database types. You can also selectively enable checks based on how rigorous you require your scans to be. For example, you can configure Burp to do a quick once-over of an application, checking only for XSS and SQL injection in URL and body parameters, before returning later to carry out more comprehensive testing of every vulnerability type in every insertion point.
Passive Scanning Areas
These options let you define which aspects of requests and responses are checked during passive scanning. The following options are available:
- Server-level issues
- MIME type
- Information disclosure
- Frameable responses ("Clickjacking")
- ASP.NET ViewState
Note that passive scans do not send any requests of their own, and each passive check imposes a negligible processing load on your computer. Nevertheless, you can disable individual areas of checks if you are simply not interested in them and don't want them appearing within scan results.
Static Code Analysis
These settings control the types of scanning that will include static analysis of executable code:
- Active scanning only
- Active and passive scanning
- Don't perform static code analysis
Note: Static analysis can consume large amounts of memory and processing, and so it may be desirable to restrict static analysis to key targets of interest. Additionally, it may be necessary to launch Burp with greater amounts of memory when performing static code analysis.
You can configure the maximum time that Burp will spend on static analysis for each individual item that is scanned. This setting can be useful if Burp encounters items containing very large or complex scripts, which may cause the static analysis engine to consume excessive system resources. If the analysis of a particular item is truncated because the maximum time was reached, then Burp shows an alert identifying the item affected. You can specify zero or a blank value to indicate that no limit should be applied.