Enterprise EditionProfessional

Auditing

• Last updated: October 29, 2024

• Read time: 10 Minutes

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.

Audit phases

Each audit comprises several phases. There are three types of audit phase:

• Passive phases.
• Active phases.
• JavaScript analysis phases.

Burp performs multiple phases within each area to allow it to:

• Find and exploit functions that store and return user input.
• Handle frequently occurring issues and insertion points efficiently, to avoid duplication.
• Execute applicable work in parallel to make best use of system resources.

Issue types found

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:

• Passive - Issues that can be detected purely by inspecting the application's normal requests and responses. For example, serialized objects in HTTP messages.
• Light active - Issues that can be detected by making a small number of benign additional requests. For example, cross-origin resource sharing (CORS) that trusts arbitrary origins.
• Medium active - Issues that can be detected by making requests that the application might reasonably view as malicious. For example, OS command injection.
• Intrusive active - Issues that can be detected by making requests that carry a significant risk of damaging the application or its data. For example, SQL injection.
• JavaScript analysis - Issues that can be detected by analyzing the JavaScript that the application executes on the client side, such as DOM-based cross-site scripting. Detecting these issues can require a significant amount of system resource. These issues can also be categorized as "passive" (for self-contained DOM-based issues) or "medium active" (for reflected and stored variants).

Issues can also be grouped by the level at which they are found:

• Host level - Issues that arise as part of the host HTTP service that the application is running on. For example, a permissive flash cross-domain policy.
• Request level - Issues that arise at the level of an individual request. For example, cross-site request forgery.
• Insertion point level - Issues that arise at the level of an insertion point within a request. For example, file path traversal.

Insertion points

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.

Encoding data within 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:

Nested insertion points

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.

Modifying parameter locations

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.

Audit prioritization

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

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.

Attack surface exposure

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:

1. List all unique insertion points identified across all potential audit items.

2. Select the audit item that encompasses the highest number of unique insertion points and add it to a separate ranking list.

3. Eliminate the insertion points encompassed by that audit item from the original list of insertion points.

4. 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.

5. Add any remaining audit items to the list.

Prioritization process

The prioritization process itself is as follows:

1. Crawl the application and determine the items to be audited.

2. Calculate the interest score.

3. Calculate the attack surface exposure score.

4. 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.

5. Sort the list of audit items by their overall score.

Automatic session handling

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:

Avoiding duplication

Burp Scanner uses various techniques to minimize duplicated effort and reporting of duplicate issues.

Consolidation of frequently occurring passive 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.

Handling of frequently occurring insertion points

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.

JavaScript analysis

Burp Scanner analyzes JavaScript within application responses to identify DOM-based vulnerabilities. To do this, Burp uses a combination of static and dynamic analysis:

• Static analysis - Burp Scanner parses the JavaScript code to construct an abstract syntax tree (AST). It identifies the tainted sources that are potentially controllable by an attacker, and the dangerous sinks that could be used to perform an attack. It also analyzes data flows through the code, to find potential paths for malicious data to be propagated from a tainted source to a dangerous sink.
• Dynamic analysis - Burp Scanner loads the response into an embedded headless browser. It injects payloads into the DOM at locations that are potentially controllable by an attacker, and executes the JavaScript within the response. It also creates mouse events to achieve as much code coverage as possible (for example, in 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

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

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.

Handling application errors

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:

• Individual audit checks.
• Individual insertion points.
• The entire request that is being audited.
• The entire scan.

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.