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:

  1. The node transparently proxies all the incoming requests until the test policy and the test run ID are sent to it.

  2. 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.

  3. If the node receives a baseline request to the target application,

    1. The node marks the incoming request with the test run ID
    2. The marked request is saved to the Wallarm cloud
    3. 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_HOSTS environment 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.com domain would be considered baseline.

    All the other requests that are not targeted to the application are transparently proxied without any modifications.

  4. The FAST node fetches all the recorded baseline requests from the Wallarm cloud based on test run ID.

  5. The FAST node generates security tests for each baseline request using the test policy received from the cloud.

  6. 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.

    FAST node internal logic

    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
  2. Execute the HTTPS baseline request you created earlier

1. Create and run the test run

  1. Log in to the My Wallarm portal using the account you created earlier.

  2. Select the “Testruns” tab and click the Create test run button. A dialog window will appear.

  3. Give a meaningful name to the test run. It is suggested in this guide that you use the name DEMO TEST RUN.

  4. Select the policy you created earlier from the “Default test policy” drop-down list. If you are following this guide, select the policy named DEMO POLICY.

  5. Select the node you created earlier from the “Node” drop-down list. If you are following this guide, select the node named DEMO NODE.

    Test run creation

  6. 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 “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 node 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 node console prints the following message: [info] The baseline #8921 is duplicated and already was processed.
    • The “Skip following files extensions” checkbox defines whether certain file types are excluded from the evaluation process during the testing. These file types are specified by the regular expression.

      For example, if you set the ico file extension to be excluded, then the GET /favicon.ico baseline request will not be checked by FAST and will be skipped.

      The regular expression can contain one of the following mutually excluding expressions:

      • .: any number of any character
      • x*: any number of the x character
      • x?: the single x character (or no character x at all)
      • any single file extension (e.g., jpg)
      • several extensions delimited by either “|” or “,” character (e.g., jpg | png or jpg, png)


      If a regular expression is not specified, then FAST will check baseline requests with any file extension.

    • The “RPS per test run” slider defines the request per second limit for the test run. This setting can take values from 1 to 1000. The default value is 1000.

    • The “RPS per baseline” slider defines the request per second limit for one baseline request. This setting can take values from 1 to 500. The default value is 500.
    • 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.

    Test run settings

  7. 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 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.

Viewing recorded baseline requests

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 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 30 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.

The result of the request execution is shown below:

The result of the request execution

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 30 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:

Incoming baseline requests

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 one XSS vulnerability for the executed HTTPS request:

The discovered vulnerability


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.

results matching ""

    No results matching ""