Нарушение контроля доступа IDOR в функционале «Забыли пароль» позволяет атакующему менять пароли

[DмᴛʀSpy]

Нарушение контроля доступа в «Забыли пароль»: как одна логическая ошибка позволяла сменить пароль любого пользователя и как это исправили​

В ходе аудита безопасности была обнаружена критическая уязвимость типа IDOR (Insecure Direct Object Reference) в механизме восстановления пароля на сайте крупного косметического бренда. Суть проблемы заключалась в том, что сервер принимал от клиента не только токен восстановления, но и открыто передаваемый идентификатор пользователя, и не проверял, принадлежит ли этот идентификатор тому же запросу на сброс, который подтверждался токеном. В результате злоумышленник, обладающий действующим токеном восстановления от своей учётной записи, мог подменить параметр с идентификатором жертвы и тем самым сбросить пароль любой другой учётной записи. Дополнительно было отмечено, что токен восстановления не аннулировался после использования и оставался действительным для повторных операций сброса, что значительно увеличивало риск захвата аккаунтов при компрометации электронной почты пользователя.

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

Отдельной проблемой было отсутствие у токенов механизма одноразовости и ограничения срока жизни.
Надёжный процесс восстановления пароля предполагает, что каждый токен привязан к конкретной сессии или запросу и становится недействительным сразу после успешного использования. Кроме того, при выдаче нового токена предыдущий должен автоматически аннулироваться, а все токены должны иметь небольшой срок жизни — обычно не более нескольких часов. Без этих мер компрометация почтового ящика жертвы приводит к долговременному риску.

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


Для разработчиков и команд безопасности ключевые выводы и рекомендации очевидны и просты в реализации: корректная авторизация и строгая проверка связки между токеном восстановления и идентификатором пользователя должны быть неотъемлемой частью логики восстановления пароля. Сервер не должен доверять клиенту в вопросе того, чей аккаунт изменяется; все решения о принадлежности токена конкретному пользователю должны приниматься исключительно на стороне сервера. Токены должны быть одноразовыми, иметь ограниченный срок действия и аннулироваться при выдаче новых. Логи и оповещения о попытках массового или аномального сброса пароля помогут выявлять и блокировать подозрительную активность на ранних этапах.

С точки зрения управления рисками полезно внедрить дополнительные меры: многофакторная аутентификация позволит минимизировать ущерб даже при успешном сбросе пароля, а уведомления на электронную почту и через SMS о фактах запроса на восстановление пароля помогут пользователям и службе поддержки оперативно реагировать на подозрительную активность. Регулярные ревизии API и тестирование на предмет IDOR-уязвимостей, а также автоматизированные сканы контроля доступа, снизят вероятность повторения подобных ошибок в будущем.

Эта история служит наглядным напоминанием о том, что даже на первый взгляд неопасные параметры запроса могут стать вектором для критических атак, если сервер доверяет входящим данным без адекватной проверки. Ответственное раскрытие и слаженная работа исследователя с командой безопасности привели к быстрому исправлению, что снижает риск для конечных пользователей. Для специалистов по безопасности важно извлечь из этого кейса практическое правило: любой объект доступа, идентифицируемый в запросе клиента, должен быть проверен и авторизован на серверной стороне; любой токен должен быть одноразовым и ограниченным по времени; и наконец, процессы восстановления пароля должны учитывать сценарии компрометации почты и предусматривать дополнительные барьеры защиты.

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