d1-docs0.1.5-u+0216

Russian

English

Russian

English

Appearance

Примеры использования ​

Так могли бы выглядеть ваши отчёты по результатам успешного скана:

badapp - dast.one/product

(Лучше бы они, конечно, не выглядели именно так, как в примерах.)

Запуск скана ​

Инструментированные контейнеры имеют установленную CMD для запуска соотв. jockey-скрипта. Т.о. внешние спецификации для запуска jockey-скрипта и контейнера совпадают.

sh
# Установите __HOSTPATH__ and __IMAGE_NAME__ в соответствии с выбранным
#   каталогом, где будет создана конфигурация и размещён результат,
#   и типом скана, т.е. соответствующим инструментом.
docker run --rm -d \
  -v __HOSTPATH__:/wrk/:rw \
  __IMAGE_NAME__  \
    -i /wrk/scanrequest.json

WebAPI (см. спецификацию OpenAPI слева в соседнем разделе) фактически является адаптером к интерфейсу контейнеров, добавляющим слои организации приложений/продуктов и диспетчеризации задач на сканы, в т.ч. параллельного запуска нескольких контейнеров.

Формат запроса на скан для контейнера и API совпадают. Схема там. А здесь пример:

json
{
  "endpoints": ["example.com"]
}
json
{
  "endpoints": ["example.com"],
  "headers": [
    ["Authorization", "Basic eW86eW8="],
    ["X-Tenant", "Custom"]
  ]
}
json
{
  "endpoints": ["example.com"],
  "headers": [
    ["Authorization", "Basic eW86eW8="],
    ["X-Tenant", "Custom"]
  ],
  "oas": {"file": "/wrk/openapi.json"}
}

demo ​

Предварительные условия

Предполагается, что в соответствии с Инструкцией для "on-premise" уже развёрнут комплект D1 и запущены соответствующие сервисы docker.

Если вы не применяли собственные настройки сетевого взаимодействия (порты, DNS, TLS и пр.), то вместо используемого в примерах "x.x.x.x" используйте IP-адрес, по которому ваш узел с запущенными сервисами Docker доступен из среды, где вы используете web-браузер.

При успешном запуске начальная страница http://x.x.x.x будет выглядеть так:

Оценочный комплект также содержит тестовое приложение – заведомо уязвимое API, которое должно быть доступно по http://x.x.x.x:10011

Создаём задачу на тестирование ​

Перейдём на страницу «Скан`запрос» ("Scan`req") и заполним форму

  • В качестве базового URL введём http://x.x.x.x:10011/

  • и установим режим тестирования: DAST либо Fuzzing – на ваше усмотрение.
    При этом:

    • При выборе Fuzzing предполагается тестирование API, поэтому будет необходимо загрузить OpenAPI-спецификацию. (См. пример vuapi-short.yaml в комплекте.)
    • Тестировать API (например, vuapi) в режиме DAST – не запрещается, но результат будет заведомо меньший.

  • для тестирования тренировочного API указывать HTTP-заголовков не нужно, но в общем виде они требуются для успешной авторизации отправляемых запросов (разумеется, если цель – протестировать сервис, а не слой контроля доступа),
    а в самом общем виде D1 позволяет автоматизировать сценарий получения (и обновления в ходе скана) заголовков/токенов.

По нажатии кнопки СКАН/FIRE вы будете перенаправлены на страницу продукта (в demo-режиме – с наименованием «klmn»), в рамках которого создалась задача.

Внимание! На данном этапе в вашем случае сканирование НЕ было запущено. Пользователь fake@dast.one, из-под которого вы работаете, имеет право запускать активные действия, но не без своего же подтверждения.

Запускаем сканирование ​

Кнопка «Run» запускает созданную задачу. При этом запускается 1-2 контейнера в зависимости от выбранного режима (вы их можете наблюдать с помощью docker ps).

В зависимости от конфигурации сканера и особенностей тестируемого сервиса, процесс может длиться до нескольких часов, но в вашем случае это должно занять до 1 минуты.

Если успеете дать запрос GET http://x.x.x.x/api/scanreq/stats, прежде чем завершится скан, сможете наблюдать подробности о текущих задачах в работе и о подзадачах сканеров:

Спустя около минуты после старта обновите страницу: вы должны заметить, что кнопка запуска скана не отображается, а под заведённой задачей на скан появился один или несколько отчётов:

Те из них, которые отмечены звёздочкой+числом, – ненулевые, они и представляют интерес.

Обратите внимание на идентификатор тестируемого приложения (в нашем примере это at-38d41de) и на URL отчёта – они нам понадобятся на следующем шаге.

Оценим результат в виде "сырых" данных ​

Оценить результат (отчёт) вы сможете самостоятельно либо с помощью разработчика, знакомого с логикой тестируемого приложения, или AppSec/DevSecOps-инженера (спец. по «безопасной разработке»).

Мы же здесь рассмотрим, где и в каком виде разместились результаты тестирования в исходном виде. Разбираем ссылку на отчёт:

.../report?report_id=app://fd/klmn/at-38d41de/r-nukem-...
URI отчёта
.../report?report_id=app://fd/klmn/at-38d41de/r-nukem-...
`id_продукта/id_приложения` – соответствует пути в файловой системе относительно значения переменной `APPDATA` в вашем `.env`

Теперь остаётся предложить рассмотреть структуру и содержание файлов и сопоставить их с тем, что происходит при старте и завершении скана:

  • app-info.json – метаданные приложения;
  • sr.json – ваш запрос на скан, используется при POST /scanreq и при запуске контейнеров (сканеров);
  • *.log – журналы, часто помогают понять причину отсутствия результата (запрос на реализацию доступа к ним из webUI/API уже в бэклоге);
  • остальное в каталоге скана – конфигурация сканера и промежуточные данные, созданные сканером;
  • остальное в каталоге приложения – ваши отчёты.

Немного подробностей о внутреннем устройстве и спецификациях: см. там.

© 2024 Метадат