Scanning phase involves analyzing traffic and application behavior to identify vulnerabilities and other issues. Burp Scanner uses a wide range of methods to provide an accurate audit of the scanned application with a high degree of coverage.
Audit stages.
Burp Scanner performs several separate audit stages. They are divided into three areas:
- Passive phase
- Active phase
- JavaScript analysis stages
Performing multiple stages in each area allows Burp to:
- Effectively discover and utilize features that store and return user input.
- Avoid duplication by handling frequently occurring issues and insertion points optimally.
- Conduct relevant work in parallel to maximize the efficient use of system resources.
Types of issues.
Burp is capable of detecting a vast array of issues, including security vulnerabilities and other interesting elements.
Issues are categorized into types based on the scanning type:
Passive – issues that can only be discovered by inspecting regular application requests and responses. For example, serialized objects in HTTP messages.
Light active – identified with a small number of additional requests. For example, cross-origin resource sharing (CORS) allows trust for arbitrary sources.
Medium active – can be detected by sending requests that the application may consider malicious. For example, operating system command injection.
Intrusive active – discovered using requests that carry a higher risk of damaging the application or its data. For example, SQL injection.
JavaScript analysis – these can be identified by analyzing JavaScript executed on the client-side by the application. For example, DOM-based cross-site scripting. Detecting these issues is often resource-intensive on the machine running Burp. These issues can also be classified as “Passive” (for autonomous DOM-based issues) or “Medium Active” (for reflected and stored variants).
Issues are further categorized into different types based on the level at which they occur:
- Host level – issues that arise at the level of the host’s HTTP service on which the application is running. For example, cross-domain flash 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.
Insertion points.
Burp uses the concept of insertion points to place meaningful payloads in different locations within requests. An insertion point is a part of data within a request that can be specially processed by the server-side application.
The following example shows a request with highlighting of some types of insertion points:
Burp Scanner checks insertion points individually, injecting payloads into each insertion point in turn to test how the application handles that input.
Data encoding in insertion points.
Typically, data in different parts of an HTTP request needs to be encoded differently. Burp Scanner automatically applies appropriate encoding to payloads based on the type of insertion point to ensure that raw payloads reach the relevant application functions.
For example, different encoding is applied to standard body parameters:
To JSON data parameters:
And to parameters containing data in XML:
Burp Scanner also detects when the application uses other encoding types not tied to the insertion point type, such as Base64:
Nested insertion points.
Some applications apply multiple levels of encoding to the same data, effectively nesting one format within another.
Burp Scanner is capable of detecting this behavior and automatically applying the same levels of encoding to payloads:
Parameter location manipulation.
Some applications place a specific part of input in one type of parameter but actually process the input if it is passed in a parameter of another type.
This occurs because some platform API interfaces that applications use for extracting input data from requests do not depend on the parameter type containing the input data.
However, some application protection mechanisms, such as Web-WAF, may only be applied to the original parameter type.
Burp can additionally exploit this behavior by changing the parameter types of insertion points to create requests that bypass protection and achieve vulnerable application functionality.
For example, if the payload data is sent in a URL query string parameter, Burp can send the payload in the body and cookie parameters.
Automatic session handling
Automatic session handling in Burp Scanner allows the scanner to use the scanning results to automatically maintain the session during the audit, using the user’s default configuration.
When Burp performs an audit of an individual request, it starts by determining the shortest path to obtain the request from the initial scanning point.
Burp then determines an efficient way to repeatedly deliver the same request during the current session.
It does this by reprocessing to get a fresh sample of session tokens and checks if it can simplify the path while ensuring the proper functioning of the current session.
In many cases, if tokens are absent, the request can be repeated multiple times.
This can be because the only session tokens are cookies, which can usually be reused:
Or it can be because although the request contains both cookies and CSRF tokens, the CSRF tokens can be reused:
In some cases, it is necessary to perform the previous request in each case before issuing the request being audited.
This usually happens because the application uses one-time CSRF tokens. Since the tokens are meant for one-time use, it is necessary to repeat the previous request each time to obtain a new token.
In extreme cases, each transition between requests is protected by a one-time token. This sometimes occurs in high-security applications where navigation is tightly controlled.
In this situation, the most reliable way to reissue a request for auditing is to always return to the initial location and navigate the full path to reach that request.
Once Burp has determined the most efficient way to retransmit the request, it proceeds with the audit.
While performing various checks, Burp periodically monitors the application’s responses to ensure the current session is maintained.
If Burp positively confirms the session’s validity, it sets a checkpoint on completed checks.
If Burp detects that the session is no longer valid, it rolls back to the last checkpoint and resumes from that point. This logic is implemented to minimize session management overhead and avoid infinite loops if sessions are frequently lost.
For example:
Duplication of issues on the target site.
Burp Scanner uses various methods to minimize duplication efforts and duplicate issue reporting.
Consolidation of frequently occurring passive issues.
Some passively detected issues may exist in many different places within the application due to the development approach or reused page templates (such as cross-site request forgery or cross-domain scripting).
Some issues may exist throughout the application due to platform-level configurations (such as weak transport security). In this situation, Burp Scanner avoids creating duplicate issues by consolidating them and reporting a single issue at the appropriate level, which could be the root web node or a folder.
Handling frequently occurring insertion points.
Some insertion points may exist in many or all requests used by the application but may not be of interest.
These include cookies and cache-busting parameters placed in the URL query strings to prevent caching but not processed by the server-side application.
Auditing these insertion points in every request would lead to unnecessary overhead.
In this situation, Burp Scanner identifies uninteresting insertion points and performs a lightweight audit of these points. If the simplified audit reveals interesting behavior indicating server-side processing, Burp continues and performs a full audit of the insertion point in the normal mode.
Analyse JavaScript
Burp Scanner is capable of analyzing JavaScript present in application responses to detect a wide range of DOM-based vulnerabilities. It employs a combination of static and dynamic analysis techniques:
- Static analysis involves analyzing the JavaScript code to construct an Abstract Syntax Tree (AST).
- Dynamic analysis loads the response into an embedded browser. It injects useful data into the DOM at potentially attacker-controlled points and executes the JavaScript in the response.
The static and dynamic approaches have different strengths and weaknesses:
Burp Scanner leverages the advantages of both static and dynamic approaches. Whenever possible, it correlates the results from both methods and reports issues with evidence obtained using both approaches.
These issues can be considered reliable findings and are reported as such. In cases where only static analysis can identify a potential issue, Burp reduces the confidence level of the reported issue.
This approach helps save time for testers when searching for critical information.
Handling application
Handling application errors is an important aspect during a full web application audit. Scanning processes often encounter issues such as connection failures, transmission timeouts, or failures in internal components. Additionally, Web Application Firewalls (WAFs) may selectively terminate connections based on specific payloads or even based on any values within parameter values.
During the audit process, Burp monitors the occurrence of error states. If a particular action triggers an error, Burp marks that action as failed and proceeds to the next action.
Since isolated errors are common, Burp first logs error details and continues the scanning process.
Once the scan is complete, if desired, Burp can perform several subsequent passes to retry the failed operations.
This can be useful in cases where a specific application component (e.g., an internal database) encountered scanning issues.
There is an option to pause or abort the scan if too many errors are observed, allowing the user to investigate the problem and resume or rerun the scan when the application stabilizes.
To initiate scanning on the target, you can start the scan and monitor the progress on the main panel.
After a successful completion of the scan, you can examine the discovered vulnerabilities in detail, along with their comprehensive descriptions in the CVE database.
This concludes the rather mundane part, and from here on, you can focus on working with different types of vulnerabilities.
