Утечка данных через сообщения об ошибках

# Утечка информации через сообщения об ошибках ## Сценарий Вы зарегистрированный пользователь интернет-магазина **SecureShop**. У приложения есть стандартный каталог товаров: можно открыть карточку товара по ID, добавить в корзину, оформить заказ. Команда уверена, что приложение готово к production — есть авторизация, CSRF-защита, параметризованные запросы. По данным внутреннего аудита, в одном из обработчиков остался отладочный вывод, который раскрывает чувствительные данные при провоцировании ошибки. Цель — извлечь флаг лабы, не имея учётной записи администратора. ## Цель 1. Найдите способ спровоцировать ошибку в одном из обработчиков (например, через обращение к несуществующему ресурсу или невалидный параметр) и изучите, какие детали сервер раскрывает в HTTP-ответе. 2. Определите, какие категории данных попадают в ответ при ошибке: технические (SQL, stack), конфигурационные (ENV, секреты), пользовательские (имена, ID). 3. Извлеките флаг лабы из ответа эндпоинта при провоцированной ошибке. ## Теория Уязвимости класса **Verbose Error Messages / Information Disclosure via Errors** возникают, когда обработчик ошибок возвращает в HTTP-ответ внутренние детали приложения: текст SQL-ошибки, stack trace, переменные окружения, имена файлов и таблиц. CWE-209 «Generation of Error Message Containing Sensitive Information», CWE-211 «Externally-Generated Error Message Containing Sensitive Information», OWASP A05:2021 «Security Misconfiguration». В реальных инцидентах через verbose-ошибки утекали AWS-ключи (через trace переменных окружения), пароли БД (через DSN в SQL-ошибке), внутренние пути к файлам (через filesystem error). **Уязвимый паттерн:** ```go // Форматирование внутренней ошибки + ENV прямо в тело ответа http.Error(w, fmt.Sprintf("query failed: %v\n--- DEBUG ---\n%s", err, strings.Join(os.Environ(), "\n")), 500) ``` Главная ловушка — комбинация: разработчик пишет «временный» отладочный вывод, чтобы быстро увидеть, что пошло не так, и забывает удалить перед коммитом или релизом. Безопасная архитектура разделяет «информацию для пользователя» (короткое generic-сообщение) и «информацию для разработчика» (детали в серверный лог через структурированный логгер). Атакующий, провоцирующий ошибку через невалидные входные данные, не должен получать в ответ ничего, чего нельзя было бы показать анонимному посетителю. ## Точка входа атаки | Параметр | Значение | |----------|----------| | Учётные данные | `demo` / `demo` | | Эндпоинт-провокатор ошибки | `GET /product/{id}` (карточка товара по ID) | | Цель | спровоцировать ошибку через невалидный/несуществующий ID и извлечь флаг из debug-секции ответа |