The logic of the extension can be described using five phases:
During the extension operation, the baseline request sequentially proceeds through the Collect, Match, Modify, and Generate phases, all of which are optional and may not be included in the extension. A single test request or multiple test requests will be formed as a result of proceeding through these phases. These requests will be sent to the target application to check it for vulnerabilities.
If no optional phases are applied to the baseline request, the test request matches the baseline request.
The use of the Detect phase is obligatory in any extension. This phase receives the responses of the target application to the test requests. The extension uses the responses to define whether the application has certain vulnerabilities. The information from the Detect phase is sent to the Wallarm cloud.
The extension is only executed for the baseline requests that satisfy the specified test policy. If the baseline request does not contain any of the parameters that the policy allows to be modified, this request is discarded and no security tests based on it are created.
In the illustration above, the FAST proxy uses the test policy that allows modifying only the GET parameter named
uid. Thus, the vulnerability search by means of the built-in FAST detects and the FAST extension will be performed for the
http://example.com/app.php?uid=123 request only.
For the second request, no vulnerability scan will be performed using either the built-in FAST detects or the FAST extension, because it does not contain a GET parameter that can be modified.
If the baseline request satisfies the test policy, it contains single or multiple parameters that can be modified. The FAST extension sequentially iterates through the set of the mutable parameters. All of the phases that are present in the extension are applied to the parameter, and the security tests are generated and executed. Then, the extension proceeds to the processing of the next parameter, until all of the parameters are processed (the POST request with the POST parameters is shown as an example in the picture below).
There can be multiple extensions. Each of the baseline requests will be processed by all the extensions that are connected to the FAST proxy.
At each moment of time, the extension processes a single baseline request. FAST supports parallel baseline request processing; each of the baseline requests received will be sent to the free worker for processing acceleration. Different workers may run the same extensions at the same time for different baseline requests. The extension defines whether test requests should be created on the basis of the baseline request.
The number of requests that the FAST proxy can process in parallel depends on the number of workers. The number of workers is defined by the value assigned to the environment variable
WORKERS upon FAST proxy Docker container execution (the default variable value is 10).