Skip to content

README.md

Latest commit

 

History

History
207 lines (157 loc) · 15 KB

README.md

File metadata and controls

207 lines (157 loc) · 15 KB

Салют 👋,
Данная лабораторная работа посвящена динамическому анализу безопасности 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.
  • 13. Почистите кеш от venv и остановите уязвимое приложение
$ deactivate
$ rm -rf venv
$ docker-compose -f docker-compose.yml down
$ docker system prune -f

Рекомендации

  • XSS на echo — отражение входных данных без экранирования

Заменить прямую подстановку строки на безопасный рендер с автоматическим экранированием или ручной фильтрацией

  • SQL Injection на search — небезопасная конкатенация строки запроса

Перейти на параметризованные запросы sqlite и передачей параметров отдельным аргументом, включая отказа от конкатенации SQL‑строк с пользовательским вводом

  • Небезопасные cookies (session, user, role ) — без  Secure,  HttpOnly, SameSite

Задать флаги  HttpOnly,  Secure (если HTTPS), SameSite=Lax/ Strict

  • Отсутствие основных security‑headers (X-Frame-Options, X-Content-Type-Options, Content-Security-Policy и т.д.)
  • Усилить авторизацию на  admin  из-за доступа по подделанному cookie
  • Directory listing на  files

Ограничить список отдаваемых ресурсов, либо скрыть directory listing, либо добавить проверки и фильтрацию путей.

Troubleshooting

Если столкнулись с проблемами — смотрите Troubleshooting.

Links