Небезопасный Сброс Пароля (IDOR)

# Захват аккаунта через небезопасный сброс пароля (IDOR) ## Сценарий Вы проводите аудит безопасности **AromaAtelier** — интернет-магазина парфюмерии на Go. Восстановление доступа устроено привычно: пользователь вводит имя на странице «Forgot Password», получает письмо со ссылкой на одноразовый токен и устанавливает новый пароль. Команда уверена, что поток безопасен: токен случаен, проверяется и удаляется после использования. У вас есть обычная учётная запись — проверьте, кого на самом деле позволяет «вылечить» этот механизм. ## Цель 1. Проследите весь путь сброса пароля и определите, какие поля финальной формы приходят с клиента и какие из них сервер действительно проверяет. 2. Найдите параметр, которому сервер доверяет без проверки его принадлежности токену. 3. Через него захватите учётную запись администратора, войдите с новым паролем и получите флаг — выкупив товар **CTF Flag** на его балансе. ## Теория Сброс пароля через письмо со ссылкой — стандартный паттерн и одновременно частый источник IDOR-уязвимостей. Корректная реализация хранит **серверную связь** токена с пользователем и при подтверждении извлекает владельца исключительно из этой связи. Уязвимая — типичная ошибка — принимает идентификатор пользователя из тела запроса клиента: «пользователь же только что заполнял форму». **Уязвимый паттерн:** ```go // Идентификатор берётся из тела запроса, а не из серверной связи токена: userID := r.FormValue("user_id") // Токен проверяется лишь на существование — без привязки к владельцу: h.db.QueryRow("SELECT COUNT(*) FROM reset_tokens WHERE token=?", token) h.db.Exec("UPDATE users SET password=? WHERE id=?", newPassword, userID) ``` Атака строится на собственном легитимном сбросе: атакующий запрашивает восстановление для своей учётки, честно получает валидный токен, но в форме подтверждения подменяет идентификатор на чужой — например, администратора. Сервер признаёт токен действительным, а пароль меняет у подставленной жертвы. Ни уязвимого токена, ни подбора пароля — только доверие сервера полю, которое контролирует клиент. ## Точка входа атаки * `POST /forgot-password` — запрос сброса, поле `username`; письмо со ссылкой видно во встроенном почтовом клиенте `GET /email`. * `GET /reset?token=...` — форма установки нового пароля. * `POST /reset` — подтверждение сброса: поля `token`, `user_id`, `new_password`. * **Обычный пользователь:** `demo` / `demo` * **После захвата:** вход администратором с новым паролем → товар **CTF Flag** в каталоге → флаг в профиле заказов