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.
Throughout this chapter the FAST proxy node will be used for creation and execution of a security test set.
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 proxy node. Then the security testing process is started on the proxy node.
FAST generates and executes a security test set in the following way:
The proxy 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 proxy node will receive the test policy and the test run ID from the Wallarm cloud.
If the proxy node receives a baseline request to the target application,
- The proxy 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
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 proxy will continue sending initial baselines to the target application.
The baseline recording begins if the proxy node receives the test policy and the test run ID first.
The FAST proxy determines if a request is a baseline one by examining the
ALLOWED_HOSTSenvironment variable. This variable was set up during the FAST proxy 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 proxy fetches all the recorded baseline requests from the Wallarm cloud based on test run ID.
The FAST proxy 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 proxy node. Testing results are associated with the test run ID and stored in the cloud.
In any given period of time, only one test run can be running on the FAST proxy node. If you create another test run for the same proxy node, the current test run execution is interrupted.
To start the security test set generation and execution process, do the following:
Select the “Testruns” tab and click the Create test run button. A dialog window will appear.
Give a meaningful name to the test run. It is suggested in this guide that you use the name
DEMO TEST RUN.
Select the policy you created earlier from the “Default test policy” drop-down list. If you are following this guide, select the policy named
Select the node you created earlier from the “Node” drop-down list. If you are following this guide, select the node named
Click the “Advanced settings” to open the list of the additional test run parameters. The following settings are available when creating a test run:
The “Run tests from the Wallarm Cloud” checkbox defines where should the test requests be generated and executed.
- If the checkbox is not checked, the requests are generated and executed on the FAST node.
- If the checkbox is checked, the requests are generated and executed on Wallarm Cloud.
The FAST node records the baseline requests in any case, regardless of the value of this setting.
The “Stop on first fail” checkbox defines whether the test run should be stopped after the first vulnerability was found.
- The “Skip duplicated baselines” checkbox defines whether the duplicates of the baseline requests received earlier should be ignored. If the FAST proxy receives the same baseline request as the one received in this test run previously, then no test requests are created on its basis, and the FAST proxy console prints the following message:
[info] The baseline #8921 is duplicated and already was processed.
- The “RPS per test run” slider defines the request per second limit for the test run. This setting can take values from
1000. The default value is
- The “RPS per baseline” slider defines the request per second limit for one baseline request. This setting can take values from
500. The default value is
- The “Stop baseline recording after” slider defines the test run time limit. This setting can take values from
5 min(5 minutes) to
1 day(24 hours). The default value is
30 min(30 minutes).
This guide uses the default test run settings.
Select the Create and run button.
Now the test run is running and the test run ID with the policy is being sent to the FAST proxy 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.
You should wait until you see the console output signalling that the FAST proxy node named DEMO NODE is ready to record baseline requests for the test run named DEMO TEST RUN.
If the proxy node is ready to record baseline request, you will see a similar message in the console output:
[info] Recording baselines for TestRun#839 ‘DEMO TEST RUN’
The proxy 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 proxy node named
DEMO NODE is ready for recording baseline requests for the test run named
DEMO TEST RUN:
To do that, navigate to the link you created using the pre-configured Mozilla Firefox browser.
The result of the request execution is shown below:
It is observable from the console output that the FAST proxy has recorded a baseline request:
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.
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 one XSS vulnerability 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 one found XSS vulnerability.