- Регистрация
- 27 Апр 2025
- Сообщения
- 51
- Реакции
- 0
- Баллы
- 6
Как я получил доступ к аккаунту без ведома пользователя через уязвимость в гостевом входе
Введение
Всем привет! Сегодня я расскажу о реальной уязвимости, которая позволила мне получить доступ к пользовательской учетной записи на одном из веб-сервисов без каких-либо действий со стороны владельца аккаунта. Всё это стало возможно благодаря неправильно реализованной функции гостевого бронирования. Этот кейс особенно интересен, так как подобные баги встречаются и в других онлайн-платформах, особенно в тех, где слабо контролируются права доступа и валидация данных.
О веб-приложении
Речь пойдет о веб-приложении, предназначенном для онлайн-бронирования билетов на автобус. Оно предлагает два режима работы: обычный вход с регистрацией и авторизацией, и более простой способ — бронирование билета как гость, где достаточно указать имя и адрес электронной почты.
Такой подход кажется удобным для пользователя, но, как оказалось, может быть опасным при неправильной реализации. На этом и строится вся атака.
Исходные данные
У жертвы уже была зарегистрирована полноценная учетная запись с адресом электронной почты victim@test.com. У меня же был свой аккаунт, с помощью которого я начал тестировать функционал.
После успешного входа в систему я начал анализировать сетевую активность и обнаружил один интересный момент — GET-запрос к API-эндпойнту, возвращающий все данные моего профиля. Для доступа использовался стандартный JWT-токен, встроенный в запрос.
JWT и первая попытка эксплуатации
JWT выглядел как типичный токен авторизации, и я сразу попробовал его расшифровать. Как и ожидалось, это оказался зашифрованный идентификатор с базовыми параметрами. Однако, поскольку подпись была надежно защищена, подделать или подменить токен не представлялось возможным.
На этом этапе я временно прекратил атаку и решил изучить гостевой режим. Я вышел из аккаунта и попытался забронировать билет, не проходя авторизацию. Система тут же предложила либо войти в существующий аккаунт, либо воспользоваться функцией «Продолжить как гость».
Суть уязвимости
Здесь и началось самое интересное. Я кликнул на кнопку гостевого входа и в соответствующие поля ввёл любое случайное имя и электронную почту жертвы (victim@test.com). После нажатия кнопки бронирования я получил ответ от сервера... с JWT-токеном этой электронной почты.
То есть, веб-приложение сгенерировало и вернуло токен доступа для существующего аккаунта, основываясь только на email, без подтверждения владения им. Это критическая уязвимость.
Эксплуатация уязвимости
Далее я скопировал полученный токен и вставил его в ранее используемый GET-запрос к API /getprofile. Как и ожидалось, API вернул данные уже не моего аккаунта, а профиля жертвы.
Теперь у меня был полный доступ к учетной записи жертвы, включая возможность:
просматривать её бронирования;
бронировать новые поездки;
отменять или изменять текущие;
изменять персональные данные.
Почему это работает
Всё дело в том, что сервер не проверял, действительно ли владелец email инициировал бронирование. Он просто выдавал токен на основе того, что этот email уже зарегистрирован, и не требовал подтверждения через код, пароль или ссылку на почте.
Это означает, что любой, кто знает адрес электронной почты зарегистрированного пользователя, может легко получить доступ к его учетной записи, просто воспользовавшись функцией гостевого бронирования.
Выводы и рекомендации
1. Никогда не доверяйте пользовательскому вводу без проверки. Даже в казалось бы безобидной форме «гостевого бронирования» скрываются потенциальные угрозы.
2. Используйте двухфакторную аутентификацию или хотя бы верификацию по email для любых операций, связанных с доступом к данным аккаунта.
3. Не допускайте генерацию токенов доступа без явного подтверждения владения учетной записью.
4. Разработчикам стоит внедрять логику, при которой при попытке гостевого бронирования на зарегистрированный email, пользователю предлагается войти в аккаунт, а не создавать временный доступ.
Финальные слова
Этот кейс — отличный пример того, как незначительная ошибка в логике авторизации может привести к серьезной утечке данных. В эпоху цифровых сервисов безопасность аккаунта должна быть приоритетом №1.
Введение
Всем привет! Сегодня я расскажу о реальной уязвимости, которая позволила мне получить доступ к пользовательской учетной записи на одном из веб-сервисов без каких-либо действий со стороны владельца аккаунта. Всё это стало возможно благодаря неправильно реализованной функции гостевого бронирования. Этот кейс особенно интересен, так как подобные баги встречаются и в других онлайн-платформах, особенно в тех, где слабо контролируются права доступа и валидация данных.
О веб-приложении
Речь пойдет о веб-приложении, предназначенном для онлайн-бронирования билетов на автобус. Оно предлагает два режима работы: обычный вход с регистрацией и авторизацией, и более простой способ — бронирование билета как гость, где достаточно указать имя и адрес электронной почты.
Такой подход кажется удобным для пользователя, но, как оказалось, может быть опасным при неправильной реализации. На этом и строится вся атака.
Исходные данные
У жертвы уже была зарегистрирована полноценная учетная запись с адресом электронной почты victim@test.com. У меня же был свой аккаунт, с помощью которого я начал тестировать функционал.
После успешного входа в систему я начал анализировать сетевую активность и обнаружил один интересный момент — GET-запрос к API-эндпойнту, возвращающий все данные моего профиля. Для доступа использовался стандартный JWT-токен, встроенный в запрос.
JWT и первая попытка эксплуатации
JWT выглядел как типичный токен авторизации, и я сразу попробовал его расшифровать. Как и ожидалось, это оказался зашифрованный идентификатор с базовыми параметрами. Однако, поскольку подпись была надежно защищена, подделать или подменить токен не представлялось возможным.
На этом этапе я временно прекратил атаку и решил изучить гостевой режим. Я вышел из аккаунта и попытался забронировать билет, не проходя авторизацию. Система тут же предложила либо войти в существующий аккаунт, либо воспользоваться функцией «Продолжить как гость».
Суть уязвимости
Здесь и началось самое интересное. Я кликнул на кнопку гостевого входа и в соответствующие поля ввёл любое случайное имя и электронную почту жертвы (victim@test.com). После нажатия кнопки бронирования я получил ответ от сервера... с JWT-токеном этой электронной почты.
То есть, веб-приложение сгенерировало и вернуло токен доступа для существующего аккаунта, основываясь только на email, без подтверждения владения им. Это критическая уязвимость.
Эксплуатация уязвимости
Далее я скопировал полученный токен и вставил его в ранее используемый GET-запрос к API /getprofile. Как и ожидалось, API вернул данные уже не моего аккаунта, а профиля жертвы.
Теперь у меня был полный доступ к учетной записи жертвы, включая возможность:
просматривать её бронирования;
бронировать новые поездки;
отменять или изменять текущие;
изменять персональные данные.
Почему это работает
Всё дело в том, что сервер не проверял, действительно ли владелец email инициировал бронирование. Он просто выдавал токен на основе того, что этот email уже зарегистрирован, и не требовал подтверждения через код, пароль или ссылку на почте.
Это означает, что любой, кто знает адрес электронной почты зарегистрированного пользователя, может легко получить доступ к его учетной записи, просто воспользовавшись функцией гостевого бронирования.
Выводы и рекомендации
1. Никогда не доверяйте пользовательскому вводу без проверки. Даже в казалось бы безобидной форме «гостевого бронирования» скрываются потенциальные угрозы.
2. Используйте двухфакторную аутентификацию или хотя бы верификацию по email для любых операций, связанных с доступом к данным аккаунта.
3. Не допускайте генерацию токенов доступа без явного подтверждения владения учетной записью.
4. Разработчикам стоит внедрять логику, при которой при попытке гостевого бронирования на зарегистрированный email, пользователю предлагается войти в аккаунт, а не создавать временный доступ.
Финальные слова
Этот кейс — отличный пример того, как незначительная ошибка в логике авторизации может привести к серьезной утечке данных. В эпоху цифровых сервисов безопасность аккаунта должна быть приоритетом №1.