Standard body parameters:
Parameters within JSON data:
Parameters within XML data:
When Burp Scanner audits during a scan, it analyzes the application's traffic and behavior to identify security vulnerabilities and other issues. Burp Scanner employs a wide range of techniques to audit the target application accurately.
Each audit comprises several phases. There are three types of audit phase:
Burp performs multiple phases within each area to allow it to:
Burp can detect a wide variety of issues of varying severity.
The issues available are grouped by the type of action Burp Scanner must take to detect them:
Issues can also be grouped by the level at which they are found:
For a full list of vulnerabilities that Burp Scanner can find, see Vulnerabilities detected by Burp Scanner.
Burp Scanner uses insertion points to place payloads into various locations within requests. In general, an insertion point represents a piece of data within a request that might be processed by the server-side application. The following example shows a request, and highlights some common types of insertion point:
Burp Scanner audits insertion points individually, sending payloads to each insertion point in turn to test the application's handling of that input.
In Burp Suite Professional, you can view a list of all the insertion points for each audited request. For more information, see Viewing insertion points.
Each insertion point typically requires a type of data encoding. Burp Scanner automatically applies encoding to payloads based on the insertion point type to make sure that the raw payloads reach the relevant application functions.
For example, Burp Suite applies the following encoding to parameters in the following insertion points:
Standard body parameters:
Parameters within JSON data:
Parameters within XML data:
Burp Scanner also detects when an application uses an encoding type that is not tied to the insertion point type, such as Base64:
Some applications apply multiple layers of encoding to the same data, to nest one format within another. Burp Scanner detects this behavior, and automatically applies the same layers of encoding to its payloads.
Some applications place an input into one type of parameter, but still process the input if it is submitted in a different type of parameter. This happens because some of the platform APIs that applications use to retrieve input from requests do not process the type of parameter that holds the input. However, some application security measures, such as firewalls, might apply to the original parameter type only.
To exploit this behavior, Burp Scanner can change the insertion point parameter types. This creates requests that might bypass protections and reach vulnerable application functionality. For example, if a payload is submitted within a URL query string parameter, Burp can also submit corresponding payloads within a body parameter and a cookie.
Before the audit begins, Burp Scanner lists the audit items in order of priority. This prioritization process ensures that the most relevant and potentially vulnerable areas of the application are audited first, improving the effectiveness of security assessments.
Burp Scanner calculates a score for each audit item based on two properties, interest level and attack surface exposure:
Interest level reflects the likelihood that an audit item will require further investigation, focusing on its potential to alter the state of the application or expose sensitive data. It's calculated by combining the contribution of an audit item's action type (40%), content type (40%), and authentication requirement (20%):
Action type. Certain types of HTTP action, such as off-spec interactions or mutations (POST, PUT, PATCH, DELETE), are considered more interesting because they are more likely to affect the application's state or expose vulnerabilities. The action type corresponds to 40% of the overall interest level.
Content type. Content types such as HTML, JSON, and XML are deemed more interesting because they are often used in data exchange. This makes them potentially more susceptible to certain types of attacks, and makes it more likely that they contain sensitive information. The content type corresponds to 40% of the overall interest level.
Authentication requirement. Burp Scanner prioritizes paths that require authentication, as they potentially lead to areas of the application that are meant to be protected or contain sensitive information. Authentication corresponds to 20% of the overall interest level.
Burp Scanner prioritizes items with the highest number of unique insertion points when auditing, as these items expose the most attack surface.
Before the audit begins, Burp Scanner uses the following process to rank audit items by the amount of attack surface they expose:
List all unique insertion points identified across all potential audit items.
Select the audit item that encompasses the highest number of unique insertion points and add it to a separate ranking list.
Eliminate the insertion points encompassed by that audit item from the original list of insertion points.
Repeat steps 2 and 3 until either all unique insertion points are covered or the remaining insertion points are already included in higher-priority items.
Add any remaining audit items to the list.
The prioritization process itself is as follows:
Crawl the application and determine the items to be audited.
Calculate the interest score.
Calculate the attack surface exposure score.
Calculate the overall score. The scores are weighted 80/20 in favor of attack surface exposure over interest. This prioritizes items offering new and unique insights into the application's security.
Sort the list of audit items by their overall score.
Audits that follow on from an automated crawl are able to use the crawl results to automatically maintain session during the audit, with no user configuration required.
When Burp audits an individual request, it identifies the shortest path to reach that request from the starting location of the crawl:
Burp determines the most efficient way to deliver that same request repeatedly within a valid session. It re-walks the path to obtain a fresh sample of session tokens. Next, it tests various simplifications of the path to see if the session is maintained even if not all of the steps in the path are followed.
In many cases, it is possible to simply reissue the final request over and over. This can happen for several reasons:
The request doesn't contain session tokens.
The application uses reusable cookies as session tokens.
The request contains both cookies and CSRF tokens, but the CSRF tokens can be used repeatedly:
Burp Scanner may need to issue the previous request before it issues the request that is being audited. This normally happens if the application uses single-use CSRF tokens. This makes it necessary to reissue the previous request on each occasion, to obtain a fresh token.
In extreme cases, every transition between requests is protected by a single-use token. This can happen in high-security applications where navigation is tightly controlled. In this situation, the most reliable way to repeatedly issue the request is to return to the starting location and walk the full path to the request.
Once Burp has determined the most efficient way to repeatedly issue the request that is to be audited, it carries out the audit.
While Burp performs its audit checks, it periodically monitors the application's responses to confirm that its session is still valid. If the session is still valid, Burp sets a checkpoint on the audit checks that are complete.
If Burp identifies that the session is no longer valid, it rolls back to the latest checkpoint and resumes from there. This helps to minimize the overhead of session management and avoids indefinite loops if sessions are frequently lost. For example:
Burp Scanner uses various techniques to minimize duplicated effort and reporting of duplicate issues.
Some passively-detected issues may exist at different locations within an application. This may be due to architecture choices or the reuse of a common page template.
Some issues may exist across the entire application due to platform-level configuration (for example, if strict transport security is not enforced).
By default, Burp Scanner aggregates any duplicates and reports a single issue at the relevant level, to avoid returning duplicated issues. This may be the web root of the host or a particular folder beneath which all of the issues are found.
Some insertion points may exist within many or all requests used by the application, but do not represent an interesting attack surface. For example, some cookies may be submitted within every request once set.
Fully auditing these insertion points in every request creates a lot of redundant work. Burp Scanner by default identifies insertion points that occur frequently but do not generate any issues, and performs a more lightweight audit of those insertion points. If the lightweight audit identifies any interesting behavior that indicates server-side processing, Burp reverts to a full audit of the insertion point.
Burp Scanner analyzes JavaScript within application responses to identify DOM-based vulnerabilities. To do this, Burp uses a combination of static and dynamic analysis:
onclick event handlers). It monitors the dangerous sinks that could be used to perform an attack and identifies any injected payloads that reach those sinks.
These static and dynamic approaches have different strengths and weaknesses.
Static analysis finds some vulnerabilities that dynamic analysis cannot. This is because static analysis can identify code paths that could be executed in the right circumstances, but which are not executed during the dynamic analysis.
For example, a branch in execution might be controlled by a number of parameters that the attacker controls. The static analysis is able to identify and analyze this branch and find taint paths within it, while the dynamic analysis might not trigger the relevant execution due to the combination of parameters required.
However, static analysis is prone to false positive results. These occur because the scan sees some combinations of code branches as executable when they are not. In addition, it doesn't understand custom data validation logic that means that tainted paths from sources to sinks are not in fact exploitable.
Dynamic analysis has the opposite characteristics. It is much less prone to false positives because it observes tainted data being propagated from source to sink during execution. This provides concrete evidence of a vulnerability.
However, dynamic analysis can suffer from false negatives in situations where the tainted data that it injects doesn't reach a sink. This can be due to the current state of the application or the values of other data, which an attacker might be able to control.
Burp Scanner harnesses the joint benefits of the static and dynamic approaches. Where possible, the system reports issues with evidence obtained from both techniques. Issues that are detected using both approaches are treated as certain. Issues that are only detected by static analysis are given a lower confidence rating.
Performing a full audit of a web application is an invasive process. It is common to encounter problems like connection failures, transmission timeouts, or back-end component outages while a scan is in progress. Additionally, protections such as web application firewalls might drop connections based on factors such as specific payloads or unexpected values in certain parameters.
While auditing, Burp tracks error conditions in a granular way. If a particular action causes an error, Burp marks that action as failed and moves on to the next action. You can configure scans so that if repeated actions fail at the same level of activity, then the whole level is marked as failed. If errors continue to occur, Burp marks progressively more of the scan as failed, as follows:
Burp initially captures details and continues to scan when it encounters an error, as isolated errors are common. Once it completes the audit, Burp performs a number of follow-up passes to retry failed operations. This is useful in cases where a particular application component (such as a back-end database) experienced a problem for part of the scan.
Burp can also pause or abort the scan if too many errors are observed, so that you can investigate the problem. You can resume or repeat the scan once the application is stable.