Приветствую тебя, на моей первой статье по циклу автоматизации OWASP ZAP и по совместительству на первой статье на форуме.
Вступление
Данная статья больше вступительная, рабочая информация начнется со второй части.
По данной теме планирую выпустить цикл статей, по мере того, как сам буду проходить те или иные этапы автоматизации. Буду эгоистичным, и скажу, что весь цикл больше предназначен для меня, чтобы структурировать полученные знания и навыки, сохранить их еще где-то, кроме поспешных записок в блокноте ну и поделиться граблями и советами, чтобы у последователей все протекло более гладко.
Какие-то части будут выходить быстро, какие-то долго, все зависит от того, прошел я данный этап или нет, и на сколько тяжело он мне дается. Также буду делиться скриптами и прочими наработками, но не всеми и некоторые вещи я не могу опубликовать, а для переписывания скриптов на тестовые среды не очень обладаю временными ресурсами, но постараюсь максимально помочь.
Стоит понимать, что автоматизированное тестирование ни в коем случае не заменяет ручные тесты. Но и ручные тесты при этом очень помогают при автоматизации (например при описании специфических правил сканирования, или последовательности шагов, чтобы подтвердить или опровергнуть багу).
Цели
Весь цикл направлен на то, чтобы автоматизировать проверку на уязвимости до выкладки кода на продуктовые сервера. В ИТ среде это называется внедрить DAST (Dinamic Application Security Testing) в DevOps pipeline. Причем целью служит не включить и забыть, а именно постепенное повышение качества тестирования и его покрытия. Внедрять различные инструменты и дополнительные фишки.
Итак, дано:
Предположим, что у нас уже отдел QA(тестировщики), что-то уже написали. У них через Jenkins либо что-то иное, по событию либо по расписанию, стартуют регрессионные тесты которые с помощью селениума и браузеров тестируют приложение на баги перед выпуском в релиз.
Целевая схема видится пока следующая:
Цель: затесаться к тестировщикам на регрессионные тесты, тем самым получив endpoints для дальнейшего сканирования. А также возможность самому по расписанию или вручную запускать DAST.(нижняя стрелочка).
Камни и почему именно пока такое решение:
При разработке по agile ключевым является скорость тестирования кода, и его поставка, важно ловить баланс между скоростью и качеством. Можно гонять DAST несколько дней, но будут при этом большие задержки доставки кода, особенно если речь про фиксы. Также можно вообще не гонять тесты, что является другой крайностью, и словить неприятные банальные ошибки как безопасности, так и функционирования приложения.
Поэтому было принято решение следующей схемы внедрения:
Описанная выше схема может измениться, где-то добавиться глубина сканирования, а где-то уменьшится, в зависимости от времени затрачиваемого на анализ. Если вы будете применять на своем продукте, то Вам самим принимать решения. По совету, лучше это обсудить с командами.
Об OWASP ZAP
Итак, почему был выбран именно OWASP ZAP? Все просто, у него хорошее api и его описание. Они первые, кто начал внедряться в DevOps. Есть плагины и множетво модулей(в нашем случае под Python). Достаточно отзывчивое комюнити.
Недостатков тоже полно. Например не совсем юзабилити по сравнению с burp, у него какая-то своя отдельная философия.
В ZAP можно писать скрипты расширения его функционировая, причем порой достаточно простыми способами, например через ZEST язык. Данные скрипты позволяют делать очень многое, прорабатывать поиски детальных багов приложения, как пример когда создается объект(пэйлоад) на одной странице, а обрабатывается пэйлоад на нескольких других страницах, следить за аномалиями и т.д.
В идеале конечно после ZAP надо внедрять и другие сканеры (Burp, w3af и т.д.) для большего покрытия и повышения шансов найти уязвимость. В данной части я хотел еще рассказать про его концепции и основные понятия, но видимо это будет описываться в следующих частях по мере работы с ними.
Необходимые навыки/знания
Для полного погружения в тему необходимо обладать, и/или желание погрузиться в следующие темы:
Что дальше?
В следующей части от размышлений, мы перейдем к практике, и я расскажу как развернуть zap на docker. В каких режимах он может там функционировать, какие образы есть. И самое главное грабли, на которые я наступил.
Вступление
Данная статья больше вступительная, рабочая информация начнется со второй части.
По данной теме планирую выпустить цикл статей, по мере того, как сам буду проходить те или иные этапы автоматизации. Буду эгоистичным, и скажу, что весь цикл больше предназначен для меня, чтобы структурировать полученные знания и навыки, сохранить их еще где-то, кроме поспешных записок в блокноте ну и поделиться граблями и советами, чтобы у последователей все протекло более гладко.
Какие-то части будут выходить быстро, какие-то долго, все зависит от того, прошел я данный этап или нет, и на сколько тяжело он мне дается. Также буду делиться скриптами и прочими наработками, но не всеми и некоторые вещи я не могу опубликовать, а для переписывания скриптов на тестовые среды не очень обладаю временными ресурсами, но постараюсь максимально помочь.
Стоит понимать, что автоматизированное тестирование ни в коем случае не заменяет ручные тесты. Но и ручные тесты при этом очень помогают при автоматизации (например при описании специфических правил сканирования, или последовательности шагов, чтобы подтвердить или опровергнуть багу).
Цели
Весь цикл направлен на то, чтобы автоматизировать проверку на уязвимости до выкладки кода на продуктовые сервера. В ИТ среде это называется внедрить DAST (Dinamic Application Security Testing) в DevOps pipeline. Причем целью служит не включить и забыть, а именно постепенное повышение качества тестирования и его покрытия. Внедрять различные инструменты и дополнительные фишки.
Итак, дано:
Предположим, что у нас уже отдел QA(тестировщики), что-то уже написали. У них через Jenkins либо что-то иное, по событию либо по расписанию, стартуют регрессионные тесты которые с помощью селениума и браузеров тестируют приложение на баги перед выпуском в релиз.
Целевая схема видится пока следующая:
Цель: затесаться к тестировщикам на регрессионные тесты, тем самым получив endpoints для дальнейшего сканирования. А также возможность самому по расписанию или вручную запускать DAST.(нижняя стрелочка).
Камни и почему именно пока такое решение:
При разработке по agile ключевым является скорость тестирования кода, и его поставка, важно ловить баланс между скоростью и качеством. Можно гонять DAST несколько дней, но будут при этом большие задержки доставки кода, особенно если речь про фиксы. Также можно вообще не гонять тесты, что является другой крайностью, и словить неприятные банальные ошибки как безопасности, так и функционирования приложения.
Поэтому было принято решение следующей схемы внедрения:
- После регрессии проводить только активное сканирование, без запуска пауков, фаззинга и больших накруток. Чтобы снизить задержку.
- Раз в неделю или пару раз в ночь проводить более детальные тесты. И найденные баги отправлять на доработку разрабам с различными приоритетами.
- Все критические баги уходят на немедленную доработку, остальные в технический долг(бэклог).
Описанная выше схема может измениться, где-то добавиться глубина сканирования, а где-то уменьшится, в зависимости от времени затрачиваемого на анализ. Если вы будете применять на своем продукте, то Вам самим принимать решения. По совету, лучше это обсудить с командами.
Об OWASP ZAP
Итак, почему был выбран именно OWASP ZAP? Все просто, у него хорошее api и его описание. Они первые, кто начал внедряться в DevOps. Есть плагины и множетво модулей(в нашем случае под Python). Достаточно отзывчивое комюнити.
Недостатков тоже полно. Например не совсем юзабилити по сравнению с burp, у него какая-то своя отдельная философия.
В ZAP можно писать скрипты расширения его функционировая, причем порой достаточно простыми способами, например через ZEST язык. Данные скрипты позволяют делать очень многое, прорабатывать поиски детальных багов приложения, как пример когда создается объект(пэйлоад) на одной странице, а обрабатывается пэйлоад на нескольких других страницах, следить за аномалиями и т.д.
В идеале конечно после ZAP надо внедрять и другие сканеры (Burp, w3af и т.д.) для большего покрытия и повышения шансов найти уязвимость. В данной части я хотел еще рассказать про его концепции и основные понятия, но видимо это будет описываться в следующих частях по мере работы с ними.
Необходимые навыки/знания
Для полного погружения в тему необходимо обладать, и/или желание погрузиться в следующие темы:
- знание основ пентеста веб-приложений
- чтение на английском
- базовые знания python
- немого знаний Docker
- представление о том, как строится разработка приложений
Что дальше?
В следующей части от размышлений, мы перейдем к практике, и я расскажу как развернуть zap на docker. В каких режимах он может там функционировать, какие образы есть. И самое главное грабли, на которые я наступил.
Последнее редактирование:
