Burp Scanner works in two different ways:
See the list of issue types for a comprehensive list of all the categories of issues that Burp Scanner can report.
In this mode of scanning, Burp takes an individual request to the application, called the "base request", and modifies it in various ways designed to trigger behavior that indicates the presence of various vulnerabilities. These modified requests are sent to the application, and the resulting responses are analyzed. In many cases, further requests will be sent, based on the results of the initial probes.
Note: This mode of operation generates large numbers of requests which are malicious in form and which may result in compromise of the application. You should use this scanning mode with caution, only with the explicit permission of the application owner, and having warned them of the possible effects that automated scanning may have on the application and its data. Ideally, scanning should be performed against non-production systems, and full backups performed prior to scanning.
There are various well-known limitations on the types of vulnerabilities within web applications whose detection can be reliably automated. Burp's active scanning capabilities are designed to focus on the kind of input-based bugs that scanners can reliably look for. By avoiding the false positives that arise in other areas, Burp gives you confidence in its output, leaving you to focus on the aspects of the job that require human experience and intelligence to deliver.
The issues that Burp's active scanning is able to identify mostly fall into two categories:
Issues in category 1 can be detected with a very high degree of reliability. In most cases, everything that is relevant to finding the bug is visible on the client side. For example, to detect reflected XSS, Burp Scanner submits some benign input in each entry point to the application, and looks for this being echoed in responses. If it is echoed, Burp then parses the response content to determine the context(s) in which the echoed input appears. It then supplies various modified inputs to determine whether strings that constitute an attack in those contexts are also echoed. Burp Scanner has knowledge of the wide range of broken input filters, and associated bypasses, that arise with web applications, and it checks for all that apply to the context. By implementing a full decision tree of checks, driven by feedback from preceding checks, Burp effectively emulates the actions that a skilled and methodical human tester would perform. The only bugs that Burp should miss are those with some unusual feature requiring intelligence to understand, such as a custom scheme for encapsulating inputs.
Issues in category 2 are inherently less amenable to automated detection, because in many cases the behaviors that are relevant to identifying the bugs occur only on the server, with little manifestation on the client side. For example, SQL injection bugs may return verbose database errors in responses, or they may be fully blind. Burp Scanner employs various techniques to identify blind server-side injection issues, by inducing time delays, changing Boolean conditions and performing fuzzy response diffing, etc. These techniques are inherently more error prone than the methods that are available in category 1. Nevertheless, Burp Scanner achieves a high success rate in this area, reliably reporting numerous kinds of issues that are difficult or laborious for a human tester to diagnose.
In this mode of scanning, Burp doesn't send any new requests to the application - it merely analyzes the contents of existing requests and responses, and deduces vulnerabilities from those. This mode of operation can be used safely and legally in any situation in which you are authorized to access the application.
Burp Scanner is able to identify numerous kind of vulnerabilities using solely passive techniques, including:
Many of these issues are relatively unexciting, and recording them is dull and repetitive for a human. But as penetration testers we are obliged to report them. Having Burp Scanner reliably mop up these issues as you browse an application is a time and sanity saver.
Being able to carry out passive-only vulnerability scanning is beneficial in a range of situations:
Get help and join the community discussions at the Burp Suite Support Center.
This release introduces a new scan check for second-order SQL injection vulnerabilities. In situations where Burp observes stored user input being returned in a response, Burp Scanner now performs its usual logic for detecting SQL injection, with payloads supplied at the input submission point, and evidence for a vulnerability detected at the input retrieval point.