Проверка состояния теста безопасности

Процессы создания и проверки тестовых запросов к приложению с помощью FAST начинаются при поступлении первого базового запроса и могут продолжаться длительное время после окончания записи базовых запросов. Вы можете контролировать ход выполнения этих процессов с помощью проверки состояния теста безопасности одним из способов:

• В интерфейсе Валарм с динамическим отображением статуса
• Однократно с помощью запроса к API

Проверка состояния через интерфейс Валарм

Состояние теста безопасности отображается в интерфейсе Валарм в реальном времени. Чтобы проверить состояние:

1. Войдите в ваш аккаунт в US‑облаке или в EU‑облаке.
2. Откройте секцию Запуски тестов и разверните необходимый тест безопасности.

Состояние отображается для каждого базового запроса:

• Пройден

  Для запроса не обнаружены уязвимости.

• В процессе

  Запрос тестируется на наличие уязвимостей.

• Не пройден

  Для запроса обнаружены уязвимости. При этом отображается количество уязвимостей и ссылка для получения деталей.

• Ошибка

  Процесс тестирования остановлен по указанной причине. Возможные причины:

  • Соединение не установлено: возникла ошибка сети
  • Авторизация не пройдена: на сервер не переданы параметры авторизации или переданы некорректные значения
  • Некорректные политики: не удалось применить заданную политику тестирования
  • Техническая ошибка: обнаружены ошибки в настройках тестирования безопасности
  • Ошибка записи: некорректные или пропущенные параметры запроса

• В очереди

  Запрос находится в очереди на тестирование.

• Прерван

  Процесс тестирования запроса был прерван вручную по кнопке Прервать тестирование, либо был инициирован новый запуск теста безопасности с той же FAST-ноды.

Проверка состояния через метод API

Для проверки состояния теста безопасности используйте следующий запрос к API:

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'

{
  "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
  }
}

При успешном выполнении запроса к API вы получите ответ от сервера, который содержит:

• vulns — массив, содержащий в себе информацию об обнаруженных уязвимостях в целевом приложении. Каждая запись об уязвимости содержит в себе следующие сведения:

  • id: идентификатор обнаруженной уязвимости.
  • threat: уровень угрозы обнаруженной уязвимости. Представляет собой число от 1 до 100. Чем больше значение параметра, тем большую опасность представляет собой обнаруженная уязвимость.
  • code: код уязвимости.
  • type: тип уязвимости. Параметр может принимать значения из списка.

• state — состояние теста. Параметр может принимать одно из следующих значений:

  • cloning: идет клонирование ранее записанных базовых запросов при копировании теста.
  • running: тест запущен и выполняется тестирование.
  • paused: выполнение теста поставлено на паузу.
  • interrupted: выполнение теста прервано (например, в результате запуска еще одного теста безопасности с указанием той же FAST-ноды).
  • passed: выполнение теста завершено успешно (уязвимостей не найдено).
  • failed: выполнение теста завершено с ошибкой (найдены уязвимости).

• baseline_check_all_terminated_count — количество базовых запросов, для которых были завершены все проверки тестовых запросов.

• baseline_check_fail_count — количество базовых запросов, для которых проверка завершилась неудачей (иными словами, была обнаружена уязвимость).

• baseline_check_tech_fail_count — количество базовых запросов, для которых проверка завершилась неудачей по техническим причинам (например, в случае временной недоступности целевого приложения).

• baseline_check_passed_count — количество базовых запросов, для которых проверка завершилась успешно (иными словами, не было обнаружено уязвимостей).

• baseline_check_running_count — количество базовых запросов, для которых выполняется проверка в текущий момент времени.

• baseline_check_interrupted_count — количество базовых запросов, для которых проверка была прервана (например, по причине прерывания выполнения теста безопасности).

• sended_requests_count — общее количество тестовых запросов, отправленных FAST к целевому приложению.

• start_time и end_time — время, когда был выполнен запуск теста и остановлено тестирование, соответственно. Значение времени задано в формате UNIX time.

• domains — список доменов целевого приложения, к которым были направлены базовые запросы.

• baseline_count — количество записанных базовых запросов.

• baseline_check_waiting_count — количество базовых запросов, для которых проверка еще не была начата.

• planing_requests_count — общее количество тестовых запросов к целевому приложению, стоящих в очереди на отправку.

Оценки скорости и времени выполнения тестирования

Отдельно следует упомянуть группу параметров в ответе сервера, позволяющую оценить скорость выполнения тестирования в текущем тесте безопасности и примерное время до завершения:

• current_rps — текущая скорость отправки запросов (в момент получения статуса теста).

  Эта величина — среднее количество запросов в секунду, отправленных FAST к целевому приложению в течение последних 10 секунд перед запросом статуса теста.

  Пример:

  Если запрос статуса теста был выполнен в 12:03:01, то current_rps рассчитывается как количество отправленных запросов в промежутке времени [12:02:51-12:03:01], деленное на 10.

• avg_rps — средняя скорость отправки запросов (в момент получения статуса теста).

  Эта величина — среднее количество запросов, отправленных за все время выполнения тестирования:

  • от старта работы до текущего момента времени, если тестирование еще выполняется (текущий момент времени - start_time);
  • от старта работы до завершения тестирования (end_time - start_time).
    
    

  Величина рассчитывается как sended_requests_count/(время выполнения тестирования).

• estimated_time_to_completion — время (в секундах), через которое ожидается завершение теста безопасности. Параметр будет иметь значение null, если:

  • проверка приложения на уязвимости еще не начата (например, если тест был только что запущен и еще не поступило ни одного базового запроса);
  • тест не выполнен (иными словами, находится в любом другом состоянии, кроме "state": "running").
    
    

  Величина рассчитывается как planing_requests_count/current_rps.

Вы можете использовать значение параметра estimated_time_to_completion для определения момента времени, когда следует выполнить следующую проверку состояния теста безопасности. Обратите внимание, что значение этого параметра может как уменьшаться, так и увеличиваться.

Пример:

Проверка состояния теста безопасности с использованием переменной estimated_time_to_completion:

1. После начала выполнения теста запросите несколько раз его состояние через небольшой интервал времени (например, 10 секунд). Дождитесь, когда значение переменной estimated_time_to_completion будет не равно null.
2. Выполните следующую проверку состояния теста через estimated_time_to_completion секунд.
3. Повторяйте процедуру из предыдущего шага, пока выполнение теста не завершится.