Timing Attack: Перечисление Пользователей

# Timing-атака: перечисление пользователей через время ответа ## Сценарий Вы проводите аудит безопасности **VaultCart** — интернет-магазина электроники на Go. При неверном входе приложение отвечает одинаковым сообщением для всех случаев — команда уверена, что защита от перечисления учётных записей реализована, и узнать, существует ли пользователь, невозможно. Ваш заказчик сомневается: «текст одинаковый — а всё остальное?» Проверьте, различимы ли сценарии по каким-то ещё осям, кроме тела ответа. ## Цель 1. Сравните поведение формы входа в трёх сценариях: несуществующий пользователь, существующий с неверным паролем, существующий с верным паролем — по статусу, телу и времени ответа. 2. Найдите боковой канал, различающий первые два сценария при идентичном ответе, и подтвердите через него существование учётной записи администратора. 3. Войдите как администратор (его пароль поддаётся словарному перебору — ограничений на попытки нет) и извлеките флаг из админ-панели. ## Теория Перечисление пользователей через **timing-канал** — класс атак, в которых существование учётной записи определяется по физическому времени обработки запроса, даже когда статус, заголовки и тело ответа неразличимы. Корень проблемы: путь обработки проходит через дорогостоящую операцию — проверку хеша пароля — только если пользователь найден; для несуществующего имени обработка обрывается мгновенно. **Уязвимый паттерн:** ```go // Дорогое сравнение хеша выполняется только для найденного пользователя: err := h.db.QueryRow("SELECT id, password FROM users WHERE username=?", username).Scan(&id, &hash) if err != nil { return // мгновенный возврат — пользователя нет } bcrypt.CompareHashAndPassword([]byte(hash), []byte(password)) // занимает десятки миллисекунд ``` Проверка хеша пароля намеренно вычислительно дорога — это её защитное свойство против офлайн-перебора. Но в timing-канале она становится маяком: ответ для существующего пользователя с неверным паролем дольше на порядки, чем для несуществующего имени. Единичный замер тонет в сетевом джиттере, поэтому атакующий снимает серии замеров и усредняет — статистика надёжно отделяет «есть такой пользователь» от «нет такого». Получив список реальных учёток, атакующий прицельно бьёт по ним: в этом приложении попытки входа ничем не ограничены. ## Точка входа атаки `POST /login` — форма входа с полями `username` и `password`. * **Рабочий пользователь (калибровка замеров):** `demo` / `demo` * **Цель перечисления и перебора:** `admin` * **Флаг:** админ-панель `GET /admin`, доступная только роли администратора