ANTICHAT - Как запустить OWASP ZAP в Docker и подключиться к API: пошаговое руководство

Приветствую на второй части статьи по OWASP ZAP. В данной статье мы рассмотрим запуск ZAP в DOCKER, а так же различные тонкие моменты его запуска, различные режимы работы и типы контейнеров.

С первой частью статью можно познакомиться тут: Автоматизация OWASP ZAP. Часть 1. Вводная часть

Почему Docker?
Тут все очевидно и просто. Докер образ нам позволяет изолировать среду, более быстро и оперативно решать проблемы, либо не решать их совсем, а просто откатываться к предыдущим версиям образов, или обнулять все конфигурации например. К тому же докер нам позволяет переносить все зависимости и всю среду AS IS(как есть) практически на любую операционную систему, а также позволяет постоянно обновляться и проводить тестирование на самых новых версиях OWASP ZAP.

Также докеризация приложений является современным мэйнстримом и некоторые CI/СD системы предпочитают работать именно с такими сервисами и приложениями. (например GitLAB c его билдером, в котором собираются приложения докер образы и доставляются на целевые хосты, а также проводятся различные тесты. Каждая система тестов должна быть запущена в своем Docker контейнере).

В общем закончим лирическое отступление, и перейдем ближе к теме. Про докер очень много везде материала, и советую с ним все таки познакомиться поближе, если вы этого еще не сделали.
У Docker есть только один пожалуй недостаток(оно так же является и преимуществом), он не сохраняет данные которые сам в себе сохраняет. Но с этой проблемой мы будем бороться ниже.

Docker образы OWASP ZAP
Тут пожалуй позволю себе переписать немного документации разработчиков. Ссылочку оставляю тут:
OWASP ZAP

Итак, OWASP ZAP имеет 4 докер образа. Обо всех по порядку:

owasp/zap2docker-stable полный стабильный образ со всеми возможными пакетами (curl, nano и т.п.) и скриптами запуска ZAP. Примерный размер 1.4 GB
owasp/zap2docker-weekly то же самое что и в п.1 только обычно правила более свежие + различные недельные доработки. Не столь стабилен как п.1. Может что-то вылезти в процессе эксплуатации.
owasp/zap2docker-live ну это в принципе еше менее стабильный релиз. Что накодили разрабы, то и зарелизили сюда.
owasp/zap2docker-bare это максимально обрезанный Docker image который как раз и предназначен для встраивания в CI/CD пайплайны, для быстрого разворачивания, переносимости и скачивания. В идеале надо пользоваться только им. Размер примерно 350 мб.

Мы же будем пользоваться образом преимущественно из п.1. Почему? Ведь мы вроде рассматриваем встраивание в CI/CD, хотим оперативного переноса контейнера и прочие плюшки? Все просто, для этого есть пару причин, а именно:

нам нужна будет отладка (curl очень нужен будет например, которого нет в обрезанной версии из п.4).
нам нужен будет один из режимов запуска zap, для удобной отладки и конфигурирования на первых шагах, а также просмотра того, что мы собственно наконфигурировали в скриптах и что происходит при сканировании. Да и происходит ли оно?

Да и честно говоря, до изучения "внутренностей" контейнера из п 4 я пока еще не дошел.

Заметка: В дальнейшем zap лучше еще установить на локальной машине, для большего быстродействия и быстрой отладки. Docker нужен на целевой хост машине, с целью исключения неприятных сюрпризов. В "идеале" настраиваться и писать скрипты сразу на хост системе, которая будет прокси сервером для браузеров с регрессионными тестами (см. мою статью часть 1), но честно признаюсь, не очень хватает нервов для этого. Поэтому лучше сделать следующее:

Развернуть целевую систему и проверить её работоспособность. Опишу в данной статье.
Установить OWASP ZAP локально, для тестирования скриптов. (можно и без этого пункта, решать вам, и устанавливать тоже).

Запускаемся

Замечание: здесь я предполагаю, что у пользователя установлены все пакеты docker и это все работоспособно. Для начала, как говорит нам документация, надо на хостовую систему скачать нужный нам image:

Bash:

Код:

docker pull owasp/zap2docker-stable

Проверить, что image скачался и есть в локальном хранилище можно так:

Bash:

Код:

root@cs30975:~

# docker images | grep zap

owasp/zap2docker-stable                         latest               a05b3e5e1979

6

weeks ago

1

.38GB

Замечание: Если у вас активно используется докер, смотрите за количестом образов хранимых на хосте. Может внезапно кончиться место. Для того, чтобы запускалась каждый раз новая версия образа, необходимо периодически удалять хранимый на хосте образ zap либо проверять обновления через команду docker pull указанную выше.

Удалять же образы можно следующим способом:

Ищем нужный образ:

Bash:

Код:

root@cs30975:~ # docker images | grep zap owasp/zap2docker-stable latest a05b3e5e1979 6 weeks ago 1 .38GB
Удаляем образ по его уникальному номеру:

Bash:

Код:

root@cs30975:~ # docker rmi a05b3e5e1979

Шаг с пулом контейнера можно пропустить, и сразу приступить к запуску контейнера. При этом если образ ранее не был скачан docker обратиться к публичному хранилищу dockerhub скачает оттуда Dockerfile и создаст докер образ. Если он был скачан и собран ранее, он возьмет готовый образ из локального хранилища. Я например сразу делал так:

Bash:

Код:

docker run --rm -u zap -p

8080

:8080 -p

8090

:8090 --name owasp-zap -d owasp/zap2docker-stable zap-webswing.sh

Кратко пробежимся по команде:

--rm - говорит о том, что контейнер будет удален, после его остановки.
-u zap -p 8080:8080 -p 8090:8090- в контейнере будет сервис запускаться под пользователем zap, у контейнера необходимо "выбросить" порты 8080 и 8090 на хостовую систему.
--name owasp-zap -даем контейнеру имя, чтобы потом с ним было проще управляться и обращаться через присвоенное нами имя, а не через его ID или случайное имя.
-d owasp/zap2docker-stable zap-webswing.sh - запускаемся в тихом режиме (-d) указываем образ который запустить, и ENTRIPOINT. Т.е. какую команду выполнить.

В данном случае, мы запускаем ZAP в режиме webswing. Ну а теперь поподробнее разберем режимы ZAP.
ВАЖНОЕ ЗАМЕЧАНИЕ:все свои конфиги, сохраненные сессии и скрипты zap хранит в домашней дирректории, т.е.

Код:

/home/zap/.ZAP/

WEBSWING
Тут мы будем работать максимально. Это самый идеальный режим для отладки. По сути это режим в котором можно управлять OWASP ZAP через полноценный GUI WEB интерфейс и в реальности смотреть, что на нем сейчас работатает, состояние сканирований и т.п.

Раз уж мы в нем запустились, давайте сразу настроимся для дальнейшей удобной работы.

Допустим, что контейнер у меня работает на серевере с IP 1.1.1.1.

Чтобы запустить ZAP и попасть в GUI надо перейти по ссылке: http://1.1.1.1:8080/zap - тут порт, который мы ранее выкидывали в запуске докер контейнера.

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

https://forum.antichat.xyz/attachmen...92d4be349f.png

После открытия, запуститься сессия ZAP.

Обратите внимание: прокси zap будет доступно по порту 8090 только после того, как вы запустите сессию, т.е. перейдете по ссылке указанной выше. Там же будет и сессия.

Итак, мы запустили сессию. Теперь давайте настроим некоторые параметры, чтобы достучаться до API ZAP. Изначально, приложение достаточно закрыто. Это надо исправить.

Идем: Tools -> Options. Выбираем раздел API. Настраиваем как на картинке.

https://forum.antichat.xyz/attachmen...519a0cf29f.png

Стоит понимать, что данные настройки только для тестовой среды. Желательно ограничить IP адресацию для которой доступна API. Я это делаю на iptables, поэтому тут разрешил все. Также можете указать свой АПИ ключ, либо выключить его, поставив галку внизу.

Также можете тут-же доставить различные Add-ons. Как это сделать, описано в документации, не буду акцентировать внимание: OWASP ZAP – ZAP Marketplace

А теперь, чтобы при каждом запуске, не изменять конфигурации давайте сохраним их на хосте. И далее сделаем так, чтобы все, что ZAP создал в ходе своей работы, мы с легкостью могли взять с хостовой системы, не боясь, что что-то удалится при очередном перезапуске контейнера. Для этого:

копируем домашнюю папку и webswing.config с контейнера на хост. Допустим у меня все будет находиться в папке

Код:

/www/owasp_zap/

Bash:

Код:

cd /www/owasp_zap/ docker cp owasp-zap:/zap/webswing/webswing.config ./webswing/webswing.configdocker cp owasp-zap:/home/zap/ ./zap/
Далее мы увидим, что все файлы у нас буду под root. Для того, чтобы все заработало и пользователь в докере смог зацепить данные файлы. На полученные папки и файлы нам надо изменить владельца. Следующими командами, узнаем uid и guid необходимые и меняем владельца.

Bash:

Код:

root@cs30975:/www/owasp_zap # docker exec owasp-zap id uid = 1000 ( zap ) gid = 1000 ( zap ) groups = 1000 ( zap ) root@cs30975:/www/owasp_zap # chown -R 1000:1000 ./zap && chown -R 1000:1000 ./webswing
теперь мы можем грохнуть контейнер

Код:

docker stop owasp-zap
И запустить его с сохраненными ранее данными.

Код:

Код:

docker run --rm -v $(pwd)/zap:/home/zap -v $(pwd)/webswing/webswing.config:/zap/webswing/webswing.config -u zap -p 8080:8080 -p 8090:8090 --name owasp-zap -d owasp/zap2docker-stable zap-webswing.sh

Как тут видно, наша команда немного увеличилась в размерах, а именно появился флаг -v (-volume). Теперь туда ZAP может записывать все свои данные, измененные конфиги и т.д, и мы их сможем оттуда забирать, а также без помощи докера отдавать ему файлы.

СОВЕТ: На начальном этапе, когда данные чистые, советую указанные папки сохранить в GIT. (в игнор можно поставить пару папок, а именно: sessions, reports). Сессии достаточно объемны (могут достигать нескольких Гб) и их сохранять не очень желательно в гите. Ну отчетам в гите тоже не место. В идеале эти папки мапить вообще не надо, а сразу запускать с нужными параметрами zap. В режиме zap.sh мы это сможем сделать. В webswing есть одно предположение как это сделать (будет озвучено ниже), но пока не пробывал. Так же вопрос возникает с добавлением Add-ons при запуске.

webswing.config
Ссылка на документацию настроек webswing оставлю здесь: Swing | Webswing Documentation

Итак. При тесте я словил баг. Что сессия у меня не хотела выходить, но при этом она не сбрасывалась и в общем в GUI я не мог попасть. Начал поиск решения проблемы. Решение заключается в данном файлике webswing.config. По факту после копирования данного файла из контейнера, советую поменять параметр:

Код:

"maxClients" : 5

(по умолчанию, значение равно 1).
Так же отмечу интересный параметр:

JSON:

Код:

"launcherConfig"

:

{

"args"

:

"-host 0.0.0.0 -port 8090"

,

Подозреваю, что это как раз и есть обходной путь из совета раздела WEBSWING. Т.е. тут в параметре args необходимо дописать с какими флагами будет запускаться zap.sh. По факту надо скопировать и вставить флаги и их данные из раздела ниже, но повторюсь, мною не тестировалось, при желании можете протестировать и отписаться в теме.

ZAP.sh режим
На самом деле это основной режим, в котором планируется постоянная эксплуатация OWASP ZAP. Т.е. режим в котором работает OWASP ZAP как прокси и доступно API. В большинстве случаев этого достаточно. Здесь не буду много расписывать. Приведу только команду запуска, как это выглядит у меня:

Bash:

Код:

docker run --rm -u zap -p

8090

:8090 --env

ZAP_PORT

=

8090

--name owasp-zap -d owasp/zap2docker-stable zap.sh -daemon -host

0.0

.0.0 -port

8090

-config api.key

=

123456789

-config api.addrs.addr.name

=

.* -config api.addrs.addr.regex

=

true

Обратите внимание, тут я не маплю папки из раздела webswing. Предполагаем, что в пайплайне это лишнее. Если мапить папки, как в разделе WEBSWING, то команда чуть измениться на и оборвется на указании порта. Если не мапить, остается открытым вопрос, по поводу сохранения установленных Add-ons. Как их доставлять и устанавливать в случае необходимости.

Справка о параметрах команды:

Код:

--env ZAP_PORT=8090

-(переписываю дефолтный порт, на котором запуститься прокси и АПИ, по дефолту это 8080)

Код:

zap.sh -daemon -host 0.0.0.0 -port 8090 -config api.key=123456789 -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

- это команда запуска демона zap.sh с определенными параметрами.

Теперь нам надо бы проверить, а запустился ли zap, и все корректно и через него можно запускать регрессионные тесты. Так сказать, надо создать некий HOOK для запуска тестов. Приведу тут команду, которой это все можно проверить в bash через утилиту zap-cli. (в будущем будет модифицироваться в Python):

Bash:

Код:

while

docker

exec

owasp-zap zap-cli  status

|

grep

-q

"ZAP is not running"

;

do

sleep

1

;

echo

"Waiting.."

;

done

Тут все просто, пока Waiting то запускаться нельзя. Тут команда больше для справки, чтобы было видно, как можно проверить готовность ZAP к работе.

Примечание:при тестировании данного режима у меня возник вопрос, а создаются ли дефолтно сессии при запуске zap.sh? И надо ли их создавать через запросы к API? Ответ был найден. Сессии создаются. И ни что не препятствует не создавать сессию, а сразу создавать контекст (при необходимости). Об этом поговорим в дальнейших частях.

API и организация к нему доступа
Предположим что мы запустились в одном из указанном режиме выше. Будем предполагать, что это режим Webswing.

Мы перешли по ссылке: http://1.1.1.1:8080/zap и запустили сессию.

Отлично. Теперь проверим работу прокси сервера:

Поставим в нашем любимом браузере proxy на 1.1.1.1 port 8090 (ведь именно там работает прокси в данном режиме судя по команде запуска докера).

https://forum.antichat.xyz/attachmen...a1bc8fc2fe.png

и попробуем открыть различные нами любимые сайты. Необходимо убедиться в том, что в http://1.1.1.1:8080/zap видно перехваченные запросы и ответы (левое окошко). По крайней мере должно так быть, после игнорирования ошибки сертификата.

Теперь нам надо попасть к API и получить его описание. Попробуем открыть:
http://1.1.1.1:8090/UI и увидим печальную надпись после долгого ожидания:

Failed to read https://1.1.1.1:8090/UI within 20 seconds, check to see if the site is available and if so consider adjusting ZAP's read time out in the Connection options panel.

Вот тут я потерял много времени. (т.к. эта ошибка может и не выводиться в принципе, а просто не открываться страница).

РЕШЕНИЕ:необходимо обращаться к api только по hostname . Т.е. по адресу http://zap:8090/UI. Поэтому для машины, с которой будете осуществлять доступ к АПИ необходимо в

Код:

/etc/hosts

прописать следующее:

Код:

Код:

1.1.1.1 zap

После этого у вас все должно заработать.

Также если вы развернули zap в docker на локальном компе, полезная команда, для получения IP zap контейнера выглядит так:

Bash:

Код:

docker inspect owasp-zap

|

grep

IPAddr

"SecondaryIPAddresses"

:

null,

"IPAddress"

:

"172.17.0.4"

,

"IPAddress"

:

"172.17.0.4"

,

Далее необходимо прописать в /etc/hosts полученный адрес по схеме выше.
Для локальной установки ZAP все работает предсказуемо, и можно зайти через http://127.0.0.1:8090

ОСТАНОВКА и удаление контейнера. Иные полезные команды
После того как попользовались, чтобы не оставлять контейнер работающим, его можно остановить командой

Код:

docker stop owasp-zap

. Т.к. мы указывали ранее флаг --rm то данный контейнер удалиться после остановки.

Также посмотреть все запущенные и работающие контейнеры можно через

Код:

docker ps

Посмотреть совсем все контейнеры( в т.ч. нештатно работающие или остановленные) можно через

Код:

docker ps -a

Удаление контейнера:

Код:

docker rm owasp-zap

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

В следующей части поговорим об основных понятиях ZAP. Возможно уже рассмотрим скрипты API на питоне. Все будет зависеть от объема данных которые будут попадать в статью.