Проверить сайт на уязвимости бесплатно: живой разбор

За 15–30 минут можно бесплатно проверить сайт на типовые уязвимости и получить отчёт с доказательствами, но не полноценное заключение о безопасности. В разборе используем OWASP ZAP 2.15.0 и локальный стенд OWASP Juice Shop: сначала пассивно смотрим запросы и заголовки, затем обсуждаем, когда допустим активный скан и почему его нельзя запускать на чужом домене.

Что именно проверяет бесплатный сканер

Сканер видит только то, до чего может добраться из HTTP-клиента. Он анализирует ответы сервера, ссылки, формы, cookies, редиректы и часть типовых сценариев. Это полезный первый фильтр, но не замена ручному тестированию авторизации, бизнес-логики и серверного кода.

На практике бесплатная проверка чаще всего находит:

• отсутствующие или слабые HTTP-заголовки безопасности;
• cookies без флагов Secure, HttpOnly или SameSite;
• раскрытие версии сервера и фреймворка;
• смешанный контент и небезопасные редиректы;
• доступные служебные страницы, каталоги и файлы;
• потенциальные отражённые параметры, которые требуют ручной проверки.

Уведомление сканера — это не доказанная уязвимость. Например, отсутствие заголовка может быть рекомендацией с низким риском, а не способом обойти авторизацию.

Бесплатный сканер отвечает на вопрос «что стоит проверить первым», а не на вопрос «сайт безопасен».

Два режима: пассивный и активный

Пассивный анализ — проверка без намеренной отправки атакующих данных. Сканер слушает обычный обмен и помечает подозрительные места^[1].

Живой пример: локальный OWASP Juice Shop

Нельзя начинать эксперимент с интернет-магазина, корпоративного портала или сайта клиента без письменного разрешения. Для безопасного примера поднимем намеренно уязвимое приложение на своём компьютере, а ZAP запустим в Docker. Версия ZAP в примере — 2.15.0; команды могут отличаться у других тегов образа.

1. Подготовьте стенд

Нужны Docker Engine или Docker Desktop, свободный порт 3000 и каталог, куда ZAP сможет сохранить отчёт. Образ Juice Shop берите из официального репозитория проекта. Он специально содержит уязвимые сценарии, поэтому не публикуйте контейнер наружу без необходимости.

docker run -d --name juice-shop -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Проверка: выполните docker ps, затем откройте в браузере http://127.0.0.1:3000. Должна появиться главная страница Juice Shop. Если порт занят, остановите другой локальный сервис или выберите другой порт и измените адрес в следующем шаге.

2. Запустите базовый пассивный скан

Команда ниже использует контейнер ZAP 2.15.0 и подключает его к сетевому пространству контейнера приложения. Параметр -t задаёт только ваш локальный адрес, а -r сохраняет HTML-отчёт в текущий каталог.

docker run --rm -t --network container:juice-shop -v "$PWD:/zap/wrk:rw" ghcr.io/zaproxy/zaproxy:2.15.0 zap-baseline.py -t http://127.0.0.1:3000 -r zap-report.html

Проверка: после завершения в текущем каталоге появится файл zap-report.html. Откройте его в браузере и сначала смотрите уровни риска, URL, параметр и доказательство, а не только итоговое число предупреждений.

3. Прочитайте одно предупреждение до конца

У каждого результата ищите четыре элемента: описание, уверенность, затронутый URL и пример ответа. Если ZAP сообщает об отсутствии заголовка, откройте именно этот ответ через DevTools или команду curl и проверьте, не добавляет ли заголовок прокси перед пользователем.

На локальном Juice Shop вы, вероятно, увидите предупреждения, которые ожидаемы для учебного приложения. Это не повод переносить их формулировки в отчёт о боевом сайте без проверки: у реального проекта другой стек, конфигурация и модель угроз.

Что выбрать для настоящего домена

Для сайта в интернете сначала выбирайте пассивный режим и ограниченный маршрут. Отключите активные атаки, если нет разрешения владельца и окна обслуживания. Даже без разрушительных payload сканер может создать сотни запросов, попасть под WAF или исказить статистику аналитики.

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

Что ломается чаще всего

• «Connection refused». Контейнер приложения не запущен, порт указан неверно или ZAP находится не в той сетевой области. Проверьте docker ps и откройте адрес браузером с хоста.
• «Unable to access the site». Целевой URL недоступен из контейнера. Для локального стенда используйте общую сетевую область, как в примере, а не случайный адрес localhost в отдельном контейнере.
• Отчёт пустой. ZAP не получил страницы или вы указали путь, который не сохранился через volume. Проверьте права на текущий каталог и наличие файла zap-report.html.
• Слишком много предупреждений. Не исправляйте всё механически. Сначала сгруппируйте находки по URL и причине, уберите дубли и подтвердите каждую проблему ручной проверкой.
• Сайт начал отвечать медленно. Остановите сканирование, проверьте логи и метрики, затем перенесите тест на стенд. Для прода задайте окно, лимиты и список разрешённых путей.

Где бесплатный скан ломается

ZAP не знает, что пользователь после смены email должен подтвердить новый адрес, а оператор не должен видеть данные другого клиента. Такие ошибки живут в бизнес-логике и требуют тестовых ролей, сценариев и ожидаемых результатов.

Автоматический отчёт также может не увидеть API, если маршрут не попал в дерево обхода, или принять защитный механизм за уязвимость. Для API нужен отдельный набор запросов и описание схемы; это отдельная тема, здесь рассматриваем только проверку доступного веб-интерфейса.

Не публикуйте отчёт с URL, cookies, внутренними именами хостов и параметрами запросов. В нём могут оказаться данные, которые опаснее самого предупреждения.

Что сделать дальше

Сохраните отчёт как исходную точку, составьте список подтверждённых проблем и назначьте каждой владельца. Для каждого исправления проверьте не только исчезновение предупреждения, но и то, что функция сайта продолжает работать.

1. Повторите пассивный скан после изменения заголовков и cookies.
2. Проверьте с тестовыми аккаунтами доступ к чужим объектам и административным маршрутам.
3. Настройте регулярный запуск на тестовом окружении, а результаты храните без секретов и персональных данных.
4. Для публичного сервиса с платежами, персональными данными или сложными ролями закажите ручной аудит, а бесплатный сканер оставьте быстрым регрессионным фильтром.