Лабораторная работа №8

Салют ,
Данная лабораторная работа посвящена динамическому анализу безопасности web‑приложений DAST с использованием OWASP ZAP. Вы развернёте уязвимое приложение в Docker, проведете ручное тестирование по инструкции для понимания принципа и логики работы, далее выполните автоматическое сканирование, проанализируете отчёт и опишете уязвимости как и каким образом они реализуются. Аналогично вы проанализируете риски ИБ и предложите меры защиты, внесете необходимые исправления.

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

Структура репозитория лабораторной работы

lab08
├── dast
│   ├── convert_reports.py
│   ├── zap_scan.sh
│   └── zap-baseline.conf
├── docker-compose.yml
├── README.md
├── requirements.txt
└── vulnerable-app
    ├── app.py
    ├── Dockerfile
    ├── files
    │   └── secret.txt
    └── requirements.txt

Материал

DAST Dynamic Application Security Testing обеспечивает тестирование «чёрного ящика», когда сканер не знает исходного кода и взаимодействует с приложением как внешний клиент:
- Отправляет HTTP‑запросы
- Анализирует ответы
- Пытается воспроизвести реальные атаки XSS, SQLi, уязвимости в заголовках, слабую авторизацию и т.д.

В отличие от SAST/ SCA, здесь обязательно нужно живое, запущенное приложение (стенд), к которому есть сетевой доступ и разрешить доступ сканеру Инструмент ведёт себя как автоматизированный атакующий: обходит страницы, подставляет полезные нагрузки payloads и фиксирует подозрительные ответы

OWASP ZAP

Особенности: - Чёрный ящик: анализ идёт по внешнему интерфейсу HTTP/HTTPS - Фокус на эксплуатацию: SQLi, XSS, LFI/ RFI, небезопасные заголовки, слабые cookies, открытые админки и т.д. Сканировать как простыми профилями baseline scan, так и агрессивными активными проверками

> - Автоматически обходить сайт `spider`/ `crawler` и находить новые эндпоинты (входные точки)
> - Выполнять пассивный анализ - заголовки, `cookies`, версии серверов, утечки данных и активные атаки `XSS`, `SQLi` и др.

Формировать отчёты в форматах HTML, JSON, XML для дальнейшего анализа и интеграции в CI/CD

Ремарка

Мы используем owasp/zap2docker-stable и CLI‑скрипт zap_scan.sh для сканирования по URL http://localhost:8080/ уязвимого приложения Flask. Скрипт запускает baseline‑скан, сохраняет отчёты и передаёт JSON на генерацию ODT/XLSX.

Задание

1. Разверните и подготовьте окружение для уязвимого приложения

$ python3 -m venv venv
$ source venv/bin/activate
$ pip install -r requirements.txt && vulnerable-app/requirements.txt

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

$ docker-compose up -d --build  # http://localhost:8080

3. Проверьте доступность приложения

$ curl -i http://localhost:8080

Вывод такой:

HTTP/1.1 200 OK
Server: xxxxx/xxxxx Python/xxxxx
Date: xxxxx, xxxxx xxxxx 2025 xxxxx GMT
Content-Type: text/html; charset=utf-8
Content-Length: 625
Set-Cookie: session=guest-session-id; Path=/
Connection: close


    <h1>Vulnerable DAST Demo App</h1>
    <p>Пример уязвимого приложения для лабораторной по DAST.</p>
    <ul>
      <li><a href="/echo?msg=Hello">Reflected XSS / echo</a></li>
      <li><a href="/search?username=admin">SQL Injection / search</a></li>
      <li><a href="/login">Небезопасный логин</a></li>
      <li><a href="/profile">Профиль (зависит от cookie)</a></li>
      <li><a href="/admin">«Админка» без нормальной авторизации</a></li>
      <li><a href="/files/">Directory listing</a></li>
    </ul>

4. Проведите ручное исследование уязвимостей и опишите почему такое происходит, каким образом реализуются уязвимости и дайте им определение
4.1. /echo - проверить отражение параметра msg в HTML и использовать payload вида <script>alert('XSS')</script> зафиксировав его поведение

http://localhost:8080/echo?msg=<script>alert('hack with XSS')</script>

4.2. /search - проверить обычный запрос ?username=admin и использовать строку ?username=admin' OR '1'='1 зафиксировав его поведение описав признак SQLi

http://localhost:8080/search?username=admin' OR '1'='1

4.3. /login - войти под admin и user проверив логику на открытые пароли и простые SQL‑запросы
4.4. /profile - изменить cookie role на admin через DevTools → Application → Cookies и обновить /profile (возможно создать cookie
4.5. /admin - проверить, что доступ запрещён без cookie role=admin и далее подделать cookie, что «админка» открывается путем изменения через DevTools. Подсказка: доступ завязан на значение cookie, без подписи/ токена/ серверной проверки.
4.6. /files/ - просмотрите directory listing и откройте один из файлов убедившись, что оно выводится

http://localhost:8080/files/secret.txt

5. Доработайте по пп 4 лабораторную работу развив их содержимое, которое может выводиться (мин 1 пример)
6. Поставьте OWASP ZAP и стяните образ конкртеной версии для него

$ brew install --cask zap
$ docker pull ghcr.io/zaproxy/zaproxy:stable

7. Задайте переменные окружения для работы скриптов

$ export ZAP_IMAGE=ghcr.io/zaproxy/zaproxy:stable
$ TARGET_URL="${TARGET_URL:-http://host.docker.internal:8080}"

8. Запустите скрипт автоматического сканирования DAST OWASP ZAP

$ ./zap_scan.sh

9. Изучите сгенерированные отчеты в dast/reports и опишите риски ИБ для них, без сценариев, так как ранее вы видели часть из их реализации
10. Внесите исправления по данному отчету DAST для vulnerable-app/app.py
11. Делайте все необходимые коммиты по шагам и отправляйте изменения в удалённый репозиторий
12. Подготовьте отчет gist.
14. Почистите кеш от venv и остановите уязвимое приложение

$ deactivate
$ rm -rf venv
$ docker-compose -f docker-compose.yml down
$ docker system prune -f

Links

Логотип