Running the test¶
This chapter will guide you through the process of generating and executing a security test set. The test set will be constructed using the test policy and baseline request you created earlier. Upon the completion of all necessary steps, you will find an XSS vulnerability as a result of your testing.
To begin application security testing, a test run should be created. Test run describes a one-time vulnerability testing process. Each test run has a unique identifier, which is crucial for correct FAST operation. When you create a test run, a test run ID and test policy are sent to the FAST node. Then the security testing process is started on the node.
FAST generates and executes a security test set in the following way:
The node transparently proxies all the incoming requests until the test policy and the test run ID are sent to it.
Given that the test run is created and run, the FAST node will receive the test policy and the test run ID from the Wallarm cloud.
If the node receives a baseline request to the target application, then:
- The node marks the incoming request with the test run ID
- The marked request is saved to the Wallarm cloud
- The initial baseline request is sent to the target application unmodified
The baseline requests recording process
This process is often referred to as baseline requests recording. You could stop the recording either from the web interface of the cloud or by making an API call to the Wallarm API. The node will continue sending initial baselines to the target application.
The baseline recording begins if the node receives the test policy and the test run ID first.
The FAST node determines if a request is a baseline one by examining the
ALLOWED_HOSTSenvironment variable. This variable was set up during the FAST node deployment process. If the request’s target domain is allowed by the variable, then the request is considered baseline. If you have followed the guide, all the requests to the
google-gruyere.appspot.comdomain would be considered baseline.
All the other requests that are not targeted to the application are transparently proxied without any modifications.
The FAST node fetches all the recorded baseline requests from the Wallarm cloud based on test run ID.
The FAST node generates security tests for each baseline request using the test policy received from the cloud.
A generated security test set is executed by sending the requests to the target application from the node. Testing results are associated with the test run ID and stored in the cloud.
Note on a test run in use
In any given period of time, only one test run can be running on the FAST node. If you create another test run for the same node, the current test run execution is interrupted.
To start the security test set generation and execution process, do the following:
1. Create and run the test run¶
Create a test run via Wallarm account web interface following the instructions.
After following the instruction, set the following basic parameters when creating a test run:
test run name:
DEMO TEST RUN;
These instructions do not contain advanced settings.
After the test run is saved, its ID will be automatically passed to FAST node. In the “Testruns” tab you will see the created test run with a blinking red dot indicator. This indicator means that baseline requests for the test run are being recorded.
You can click on the “Baseline req.” column to see all the baseline requests that are being recorded.
The node readiness for the recording
You should wait until you see the console output signalling that the FAST node named
DEMO NODE is ready to record baseline requests for the test run named
DEMO TEST RUN
If the node is ready to record the baseline request, you will see a similar message in the console output:
[info] Recording baselines for TestRun#N ‘DEMO TEST RUN’
The node will be able to generate a security test set based on the baseline requests only after this message is shown.
It is observable from the console output that the FAST node named
DEMO NODE is ready for recording baseline requests for the test run named
DEMO TEST RUN:
[info] Node connected to Wallarm Cloud [info] Loaded 0 custom extensions for fast scanner [info] Loaded 51 default extensions for fast scanner [info] Waiting for TestRun to check... [info] Recording baselines for TestRun#N 'DEMO TEST RUN'
2. Execute the HTTPS baseline request you created earlier¶
To do that, navigate to the link you created using the pre-configured Mozilla Firefox browser.
Example of a link
The result of the request execution is shown below:
It is observable from the console output that the FAST node has recorded a baseline request:
[info] Node connected to Wallarm Cloud [info] Loaded 0 custom extensions for fast scanner [info] Loaded 51 default extensions for fast scanner [info] Waiting for TestRun to check... [info] Recording baselines for TestRun#N 'DEMO TEST RUN' [info] Proxy request GET https://google-gruyere.appspot.com/430232491618310677730226710602783767322/snippets.gtl?password=paSSw0rd&uid=123 [info] Running a test set for the baseline #X
You can observe some baseline requests being saved to the Wallarm cloud:
This document suggests that only one request be executed for demonstration purposes. Given that there are no additional requests to the target application, stop the baseline recording process by selecting the Stop recording option from the “Actions” drop-down menu.
Controlling the test run execution process
A security test set was generated quite fast for the test run you created. However, the process could take a significant amount of time, depending on the number of baseline requests, the test policy in use, and the responsiveness of the target application. You could pause or stop the testing process by selecting an appropriate option from the “Actions” drop-down menu.
The test run stops automatically when the testing process is finished, given that no baseline recording is in progress. Some brief information about the detected vulnerabilities will be displayed in the “Result” column. FAST should find some XSS vulnerabilities for the executed HTTPS request:
Now, you should have all of the chapter goals completed, along with the result of testing the HTTPS request to the Google Gruyere application. The result shows three found XSS vulnerabilities.