Introduction
The scanning phase in Burp Suite is a critical step in the process of assessing the security of web applications. It involves analyzing web traffic and the application’s behavior to identify vulnerabilities and potential issues. Burp Scanner, a component of Burp Suite, employs a wide range of methods to conduct an accurate audit of the scanned application with a high degree of coverage.
The scanning phase consists of several distinct stages, categorized into three areas:
Passive Phase: This phase involves passive scanning, where Burp Scanner observes and analyzes the regular traffic between the client and the web server. It looks for vulnerabilities and issues that can be detected by inspecting regular requests and responses. For example, it may identify serialized objects within HTTP messages.
Active Phase: In the operational phase, Burp Scanner actively sends additional requests to the application to identify vulnerabilities that require more interaction. This includes issues that may not be evident in passive scanning alone. An example is the discovery of Cross-Origin Resource Sharing (CORS) misconfigurations, which trust arbitrary sources.
JavaScript Analysis Phase: Burp Scanner also conducts an analysis of JavaScript executed on the client side. This phase focuses on issues related to client-side scripts and can be resource-intensive. Examples of problems that can be discovered in this phase include DOM-based Cross-Site Scripting (XSS).
Performing multiple stages in each of these areas allows Burp Scanner to:
- Effectively identify and exploit functions that store and return user input.
- Avoid duplication by handling commonly occurring problems and insertion points optimally.
- Execute relevant work in parallel to maximize the efficient use of system resources.
Vulnerability Types
Burp Scanner is capable of detecting a wide range of security issues and vulnerabilities in web applications. These vulnerabilities are categorized based on the type of scanning they require:
Passive Vulnerabilities: These vulnerabilities can only be identified by inspecting regular requests and responses. Examples include issues related to serialized objects in HTTP messages.
Light Active Vulnerabilities: They are discovered by sending a small number of additional requests. An example is identifying Cross-Origin Resource Sharing (CORS) misconfigurations that trust arbitrary sources.
Medium Active Vulnerabilities: These vulnerabilities can be detected by sending requests that the application might consider malicious. Examples include Command Injection vulnerabilities.
Intrusive Active Vulnerabilities: These vulnerabilities are identified through requests that carry a higher risk of damaging the application or its data. SQL Injection is an example.
JavaScript Analysis Vulnerabilities: These issues are discovered by analyzing the JavaScript executed on the client side. They can be identified by analyzing the JavaScript that the application performs on the client side. For example, DOM-based cross-site scripting. Detecting these issues is often resource-intensive on the machine running Burp. These problems can also be classified as “Passive” (for standalone DOM-based issues) or “Medium Active” (for reflected and stored variants).
These vulnerability types can be further categorized based on the level at which they exist:
Host Level: Issues occurring at the HTTP host service level. For instance, issues related to Cross-Origin Resource Sharing (CORS) policies.
Request Level: Problems that affect individual requests, such as Cross-Site Request Forgery (CSRF).
Insertion Point Level: Vulnerabilities that exist at specific insertion points within requests. This could include file path-related issues.
Insertion Points
Burp Scanner employs the concept of insertion points to place payloads (useful data) at various locations within requests. An insertion point represents a part of the request data that may be specially processed by the server-side application.
In the example below, a request is highlighted with some types of insertion points:
Burp Scanner checks insertion points individually, injecting payloads into each insertion point one by one. This approach is used to assess how the application handles different input forms.
Encoding Data in Insertion Points
Typically, data within different parts of an HTTP request should 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 intended application functions correctly.
For example, different encoding is applied to standard body parameters:
For parameters in JSON data:
For parameters containing data in XML:
Burp Scanner also detects when an application uses other types of encoding that are not specific 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 encoding levels to payloads:
Changing Parameter Locations
Some applications place a specific part of input into one type of parameter but actually process the input if it’s passed in a parameter of another kind. This occurs because specific platform API interfaces that applications use to extract input data from requests do not depend on the parameter type containing the input data.
However, some application security mechanisms, such as Web Web Application Firewalls (WAFs), may only apply to the original parameter type.
Burp can leverage this behavior by changing the parameter types of insertion points to create requests that bypass protection and reach vulnerable application functionalities.
For example, suppose the valuable data is sent in a URL query string parameter. In that case, Burp can send the payload in both the body and cookie parameters to take advantage of this behavior.
Automatic Session Handling
When conducting automated audits, the scanner can use scan results to automatically handle sessions during the audit with the default user configuration.
When Burp performs an audit of an individual request, it starts by determining the shortest path to get the request from the initial scanning point:
Burp then determines the most efficient way to deliver the same request during the current session repeatedly. It does this by revisiting to obtain a fresh sample of session tokens and checking the feasibility of simplifying the path while ensuring the current session functions correctly.
In many cases, if tokens are absent, the request can be repeated multiple times:
Or because cookies are typically reusable:
Or because the request contains both cookies and CSRF tokens, and CSRF tokens can be reused:
In some cases, it’s necessary to replay the previous request each time before issuing the tested request. This usually happens because the application uses one-time CSRF tokens. Since CSRF tokens are designed for one-time use, it’s 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 use token. This occasionally happens in high-security applications where navigation is tightly controlled.
In this situation, the most reliable way to replay a request for an audit is to always return to the initial location and go through the full path to that request:
Once Burp has determined the most efficient way to replay a request, it conducts the audit. While performing various checks, Burp periodically monitors application responses to ensure the current session is being maintained.
If Burp positively confirms the session’s validity, it sets a checkpoint on checks that have been fully completed. 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 in case sessions are frequently lost.
Duplication of Issues on the Target Site
Burp Scanner uses various methods to minimize duplication of efforts and reports on duplicate issues.
Consolidating Frequently Occurring Passive Issues.
Some passively discovered issues may exist in many different places within the application due to the development approach or the reuse of page templates (e.g., CSRF or cross-domain scripting). Some issues may exist throughout the entire application due to platform-level configuration (e.g., lack of strict transport security). In this situation, Burp Scanner avoids creating duplicate issues by consolidating them and reporting a single issue at the appropriate level, which can be the root web host node or a folder.
Handling Frequently Encountered Insertion Points
Some insertion points may exist in many, or all requests the application uses but may not be interesting.
Examples include cookies and cache buster 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 can result in excessive overhead. In such cases, Burp Scanner identifies uninteresting insertion points and proceeds to perform lightweight audits of these points. If the simplified audit reveals interesting behavior that indicates server-side processing, Burp continues to work and performs a full audit of the insertion point in normal mode.
JavaScript Analysis
Burp Scanner analyzes JavaScript contained in application responses to detect a wide range of DOM-based vulnerabilities. It does this by using a combination of static and dynamic analysis:
- Static analysis involves analyzing JavaScript code to build an abstract syntax tree (AST).
- Dynamic analysis loads the response into a built-in browser. It injects useful data into the DOM at potentially attacker-controllable places and executes JavaScript in the response.
Both static and dynamic approaches have different strengths and weaknesses.
Burp Scanner leverages the benefits of both methods. Where possible, it correlates the results of both methods and reports issues with evidence obtained from both methods.
These issues can be considered reliable findings, and they are reported as such. In cases where only static analysis can potentially discover a problem, Burp reduces the reliability of the issue report.
This approach helps testers save time when searching for critical information.
Handling Application Errors
Conducting a full audit of a web application can be an intrusive process, and issues such as connection failures, transmission timeouts, or internal component failures often occur during scanning. Additionally, Web Web Application Firewalls (Web-WAFs) may selectively reset connections based on specific payloads or even based on any values in parameter values.
During the audit, Burp tracks the occurrence of error states. If a specific action triggers an error, Burp marks that action as unsuccessful and moves on to the next action. Since isolated errors are common, Burp first logs error details and continues scanning.
When the scan is completed successfully, Burp can perform multiple subsequent passes to replay unsuccessful operations if desired. This can be useful in cases where a specific application component (e.g., an internal database) encounters scanning issues.
There is an option to pause or abort scanning if too many errors are encountered, allowing the user to investigate the issue and resume or re-scan when the application stabilizes.
Start scanning on the target object:
On the main panel we can track the scanning progress:
After successful completion of the scan, we can review in detail the detected vulnerabilities and their detailed description in the CVE database.
This, also quite boring part, is over, then work with various types of vulnerabilities only.
