Добрый день.
Опишу случай, который произошёл с моим другом, и попрошу разработчиков/технических специалистов прокомментировать.
Ситуация:
Друг получил ссылку на официальный сайт игры вида:
https://exbo.net/?__cf_chl_rt_tk=9gHtX2qLpW8aYz4uNrBvKcZsTmF6bQpR0xHjLwEo-4829057163-2.7.4.3-AkPq4ZrT981sVbM6nYpQx3LuWzF9c_Je3D
(ссылка не оригинальная, символы заменены на случайные)
На момент перехода он уже был авторизован в аккаунте.
Логин и пароль нигде не вводились.
После перехода аккаунт оказался украден: злоумышленники вошли без запроса пароля и без прохождения 2FA.
Предположения:
Кража сессии (session hijacking):
Вероятно, были украдены session cookies или токен авторизации, которые затем подставили в браузере атакующего.
Это объясняет обход 2FA: проверка выполняется только в момент логина, а при подмене действующей сессии сервер считает пользователя уже аутентифицированным.
Session fixation / авторизационный токен в URL:
- Теоретически возможно, что в ссылке передавался session id или другой идентификатор, который был привязан к атакующему.
- После перехода браузер жертвы «подсадил» этот идентификатор, а атакующий использовал ту же сессию у себя.
- Но в данном случае параметр __cf_chl_rt_tk больше похож на служебный токен Cloudflare для антибот-проверки.
CSRF маловероятен:
Эта атака позволяет выполнять действия от имени пользователя, но не даёт украсть сессию и использовать её на другом устройстве.
Важные технические моменты:
- Если критичный авторизационный токен хранится в localStorage или в cookies без флага HttpOnly, то его реально украсть через JS-инъекцию (XSS).
- Если токен/сессия передаётся через URL (GET-параметры), он может утекать через рефереры, логи или сторонние скрипты.
- Если при переходе по ссылке Cloudflare отдаёт challenge-страницу с JS, возможно злоумышленники встроили в цепочку редирект со скриптом, который эксфильтровал данные.
Что я бы хотел уточнить у разработчиков:
- Используются ли для авторизации только cookies с флагами HttpOnly, Secure, SameSite=Strict?
- Может ли токен авторизации храниться в localStorage (и быть доступен JS)?
- Возможна ли привязка сессии к IP/устройству, чтобы затруднить использование украденных cookies?
- Есть ли проверка на повторное использование одного session id с разных IP/UA за короткий промежуток времени?
- Может ли параметр __cf_chl_rt_tk каким-либо образом использоваться для фиксации сессии?
Просьба:
- Подтвердить или опровергнуть возможность session hijacking через подобный сценарий.
- Посоветовать, какие дополнительные меры безопасности можно предпринять (со стороны пользователя и со стороны сервиса).
- При возможности проверить логи по времени инцидента: совпадают ли IP и User-Agent у сессии жертвы и у злоумышленников.
ник уебка, который данную ссылку предоставил Shilov
ник моего пострадавшего товарища Pitseed
