Checking Status of Test Run

Chapter Prerequisites

To follow the steps described in this chapter, you need to obtain:

  • A token.
  • An identifier of a test run.

    The following values are used as example values throughout the chapter:

  • token_Qwe12345 as a token.
  • tr_1234 as an identifier of a test run.

The processes of creating and executing the test requests begin when the first baseline request is recorded and could last a significant amount of time after the process of baseline requests recording has been stopped. You could check the state of the test run periodically to get some insights into the performing processes.

You could perform a single check of the test run state by issuing the following API call:

GET

Do One-Time Check of Test Run State

https://us1.api.wallarm.com/v1/test_run/test_run_id
API call: GET /v1/test_run/test_run_id
Authorization: Required With the token
HTTP header with the token: X-WallarmAPI-Token Serves to pass the token’s value to the API server
Parameters: test_run_id (required) The identifier of the test run whose state to obtain



Example of a request:

curl --request GET \
  --url https://us1.api.wallarm.com/v1/test_run/tr_1234 \
  --header 'Host: us1.api.wallarm.com' \
  --header 'X-WallarmAPI-Token: token_Qwe12345'

Example of a response:

{
  "status": 200,
  "body": {
    "id": tr_1234,
    "name": "demo-testrun",
    "vulns": [
      {
        "id": vuln_0001,
        "threat": 80,
        "code": "S0001",
        "type": "sqli"
      }
    ],
    "clientid": demo_0000,
    "state": "failed",
    "simple_state": "failed",
    "allowed_actions": [],
    "baseline_check_all_terminated_count": 1,
    "baseline_check_fail_count": 1,
    "baseline_check_tech_fail_count": 0,
    "baseline_check_passed_count": 0,
    "baseline_check_running_count": 0,
    "baseline_check_interrupted_count": 0,
    "sended_requests_count": 70,
    ...
    "start_time": 1555572038,
    "end_time": 1555572309,
    ...
    "domains": [
      "app.example.local"
    ],
    "baseline_count": 1,
    ...    
    "baseline_check_waiting_count": 0,
    "planing_requests_count": 70
  }
}

If the request to the API server is successful, you are presented with the server’s response. The response provides a lot of useful information, including:

  • vulns: an array that contains information about the detected vulnerabilities in the target application. Each of the vulnerability records holds the following data regarding the certain vulnerability:

    • id: an identifier of the vulnerability.

    • threat: a number in the range from 1 to 100, that describes the threat level for the vulnerability. The higher the level is—the more severe the vulnerability is.

    • code: a code assigned to the vulnerability.

    • type: a type of the vulnerability. The parameter can take one of the following values:

      • anomaly—anomaly.
      • auth—authorization bypass.
      • csrf—Cross-Site Request Forgery.
      • idor—Insecure Direct Object Reference.
      • info—information disclosure.
      • ldapi—LDAP injection.
      • nosqli—NoSQL injection.
      • ptrav—Path Traversal.
      • rce—Remote Code Execution.
      • redir—Open Redirect.
      • sqli—SQL injection;
      • ssrf—Server-Side Request Forgery.
      • ssti—Server-Side Template Injection.
      • xss—Cross-Site Scripting;
      • xxe—XML External Entity attack;
  • state: the test run’s state. The parameter can take one of the following values:

    • running: the test run is running and executing.
    • paused: the test run execution is paused.
    • interrupted: the test run execution is interrupted (e.g. the new test run for the FAST node was created while the current test run was being conducted by this node).
    • passed: the test run execution is completed successfully (no vulnerabilities were found).
    • failed: the test run execution is completed unsuccessfully (some vulnerabilities were found).
  • baseline_check_all_terminated_count: a number of baseline requests for which all of the test request checks are completed.

  • baseline_check_fail_count: a number of baseline requests for which some of the test request checks are failed (in other words, FAST found a vulnerability).

  • baseline_check_tech_fail_count: a number of baseline requests for which some of the test request checks are failed due to the technical issues (e.g. if the target application was unavailable for some period of time).

  • baseline_check_passed_count: a number of baseline requests for which all of the test request checks are passed (in other words, FAST did not find a vulnerability).

  • baseline_check_running_count: a number of baseline requests for which the test request checks are still in progress.

  • baseline_check_interrupted_count: a number of baseline requests for which all of the test request checks were interrupted (e.g. due to interruption of the test run)

  • sended_requests_count: a total number of test requests that were sent to the target application.

  • start_time and end_time: time when the test run started and ended, respectively. The time is specified in the UNIX time format.

  • domains: a list of the target application’s domain names the baseline requests were targeted to.

  • baseline_count: a number of recorded baseline requests.

  • baseline_check_waiting_count: a number of baseline requests that are waiting to be checked;

  • planing_requests_count: a total number of test requests that are queued to be sent to the target application.

It is possible to make a conclusion regarding the presence or absence of vulnerabilities in the application on the basis of the state and vulns parameters’ values.

Example.

A process, that is querying the test run state by making the API call periodically, could terminate with the exit code 0 if there was the state:passed parameter found in the API server’s response and with the exit code 1 if there was the state:failed parameter found in the API server’s response.

The exit code value could be employed by the CI/CD tool in order to calculate the overall CI/CD job’s status.

It is possible to establish even more complex logic of how the FAST-enabled CI/CD job should interact with the CI/CD tool. To do so, use other pieces of data that could be found in the API server’s response.

You could go back to the list of FAST integration's steps if necessary.

results matching ""

    No results matching ""