Troubleshooting Slow Scanner Issues

When performing automated testing using Burp Scanner, you may occasionally observe the Scanner running slower than you are accustomed. It could be any number of things causing Burp Scanner to run slowly.

The following steps can enhance the speed of your scanning, however, the tester should use his knowledge of the application and the requirements of the test to find a suitable trade-off between speed and accuracy.

1. Application size


The size of an application can dramatically effect the duration of a Burp Scan.

You can use the filters in the Active scanning wizard to remove certain categories of items, to make your scanning more targeted and efficient.

Alternatively, you can manually add targets to the scan queue, ensuring you only scan exactly what is required.




2. Attack Insertion Points

The Attack Insertion Point settings (Scanner > Options) control how the Scanner places "insertion points" into each base request that is sent for active scanning.

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.


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.

You can reduce the volume of work that Burp Scanner has to process by skipping parameters that repeat in separate areas of an application.


3. Slow application / connection errors


If you find that connection errors are occurring or that the application is slowing down, you should reduce the thread count, and maybe increase the number of retries on network failure and the pause between retries.

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.


4. Scan Optimization Settings


The scan optimization settings let you tune the behavior of the active scanning logic to reflect the objectives of the scan and the nature of the target application.

The "Fast" setting speeds up the scanning by making fewer requests, and checks for fewer derivations of some vulnerabilities.

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.

Intelligent attack selection makes scans more efficient by omitting checks that appear irrelevant given the base value of the parameter at each insertion point.


5. Scan Issues Configuration


Each check that is performed increases the number of requests made, and the overall time of each scan.

You can reduce the time it takes to scan an application by selecting a different scan type or by turning off individual checks 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.

It is worth noting that attacks involving time-delay checks can be problematic when attempting to enhance the speed of a scan.


6. Static Code Analysis


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.

In some situations it may be appropriate to avoid scanning JS frameworks entirely to enhance the speed of your scanning.