FAST is a two-component solution, comprising the FAST proxy and the Wallarm cloud.
To conduct application testing, HTTP or HTTPS requests are proxied through the FAST proxy first. FAST creates a new request set based on the original queries according to policy obtained from the cloud. The newly created requests form a security test set that is executed in order to test the application for vulnerabilities.
Baseline requests (the original requests to the applications) can be obtained from different sources. For example, baseline requests can be written by an application tester or generated by an existing testing automation tool. FAST does not require all of the baseline requests to be malicious ones: a security test set could be generated based on legitimate requests as well.
The main FAST usage scenario assumes that the FAST proxy is used for security test set creation and execution purposes. However, the test set could be created and executed on the Wallarm cloud, if necessary. This guide will introduce you to the main usage scenario.
You have a choice of three FAST proxy deployment options. The proxy installation could be located at
- The host that serves as a baseline request source (a tester’s laptop, for example)
- The host where the target application resides
- The dedicated host
FAST proxy is shipped as a Docker container and could be run on every platform that supports Docker (this includes Linux, Windows and macOS).
An account in the Wallarm cloud is a mandatory requirement for FAST deployment. The cloud is responsible for providing a user interface for FAST configuration. The testing results are also gathered by the cloud.
After completing the FAST proxy deployment you should ensure that
- The proxy node has access to the target application
- The proxy node has access to the Wallarm cloud
- All the baseline HTTP or HTTPS requests will be proxied through the proxy
If you intend to use Wallarm cloud for security test set generation and execution processes, you should provide access from the Wallarm cloud to your proxy installation.
In the case of using HTTPS to interact with the target application, the request source might not trust the self-signed SSL certificate obtained from the FAST proxy installation (or FAST proxy node in other words). For example, if you use the Mozilla Firefox browser as the requests source, you may encounter a similar message (it may differ for other browsers or request sources):
To resolve the certificate issue, you have two options:
- To install the self-signed SSL certificate from FAST proxy node as a trusted certificate to the request source
- To install the existing trusted SSL certificate to your FAST proxy node
This guide aims to demonstrate the FAST operation by exploiting the deployment option where the proxy node is installed locally with the request source.
The installation that is used in this guide has the following specifics:
- The Mozilla Firefox browser serves as the baseline request source
- One HTTPS baseline request is constructed
- A self-signed SSL certificate from the FAST proxy node is installed into the browser
- Google Gruyere serves as the target application
- The target application is tested against XSS vulnerabilities
- The policy is created with the web interface of Wallarm cloud
- The testing process is started with the web interface of Wallarm cloud
Google Gruyere is a purpose-built application for security testing. It contains a lot of intentionally integrated vulnerabilities. Therefore, every application instance runs in an isolated sandbox for security reasons. To begin working with the application, you should navigate to https://google-gruyere.appspot.com and run a sandbox with the separated instance of Gruyere application.