Защита ТГ webapp от мультисессий?

Question

[Maksim Herasim]

Делаю Mini App для ТГ.
Есть бот в котором происходит предварительная регистрация (общедоступный псевдоним, пол), далее бот кидает ссылку на mini app в которой есть мини игры, в т.ч. против других игроков.
Задача:
1) Запретить возможность открывать mini app с одного аккаунта на нескольких устройствах
2) Защита аккаунта от перехвата сессионных ключей
Как вижу это я:
ШАГ 1

1) При переходе из бота пользователя переходит на страницу /one
Туда подключен telegram-web-app.js для получения сведений о пользователе.
а) удаляем все кукисы
б) устанавливаем временный кукис в виде зашифрованного json который содержит в себе ts входа и некое ключевое слово (шифрованное значение приходит с backend, а не шифрутеся на стороне клиента). Шифрование 3DES с 64 битным ключом.
в) проверяем что пользователь открыл приложение именно через клиент ТГ(window.Telegram && Telegram.WebApp)
г) получаем от пользователя username + id.
д) перекидываем пользователя на страницу /two с параметрами /two?username=$username&userid=$id

Шаг 2

а) на backend читаем кукисы и расшифровываем строку. Если строка содержит ключевое слово + ts не старше 30 секунд + userid совпадает с userid в параметрах, идем к следующему шагу.
б) проверяем username и userid в БД, есть ли в бд или нет (прошли регистрацию?) Если есть, идем к следующему шагу.
в) удаляем кукисы
г) По websocket приходит json который содержит в себе новый зашифрованный кукис (на беке эта сессия добавляется в memcached)
д) перенаправляем пользователя на страницу /app без параметров, только с временной кукой

ШАГ 3

а) читаем кукис и расшифровываем
а1) проверяем что нет флага relaod
б) сверяем чтобы кукис был в memcache
в) сверяем что кукис не старше 30 секунд
г) расшифровывем кукис и устанавливаем на фронте параметры из кукиса
д) очищаем кукисы
е) устанавливаем новый кукис в котором будет флаг - reload:yes
ж) далее все данные гоняются через websocket. Если пользователь обновит страницу - его перекинет на /one и процедура авторизации начнется сначала
з) если пользователь войдет с другого устройства (с другого окна), в БД перезапишется активная сессия и по websocket пользователю прилетит событие что вы были авторизованы в другом окне, обновите страницу.

Вопрос, какие +\- можете сказать по такой схеме? Слабые\узкие места которые видите Вы?
Синтезировал 1000 - 10 000 одновременных открытий: дельта открытия приложения составила против 8 секунд (имеется ввиду разницу между 1000 и 10 000.
/one, /two, /app сделано из за особенностей реализации, можно было бы упростить до 1 перехода, но в моем случаем так нужно для масштабируемости (потенциально)
P.S. Из memchache я удаляю сессию после чтения на 3 шаге
P.P.S. я периодически обновляю сессионный кукис на шаге 3 через websocket

Answer 1

[Everything_is_bad]

А зачем эти one, two, бессмысленное шифрование, какой-то непонятный набор действий, как это вообще связанно с для масштабируемостью?
Достаточно сразу коннетиться к вебсокет, а на сервере разрешить только один коннект от телеграм id

Comments

[Maksim Herasim]

как это вообще связанно с для масштабируемостью?

Разнесение серверов авторизации и серверов приложения на разные инстансы. В случае падения серверов авторизации - уже действующие клиенты останутся подключенными.

А зачем эти one, two, бессмысленное шифрование, какой-то непонятный набор действий

На втором шаге также запрашивается пароль установленный пользователем. Не описал, т.к. посчитал не нужным.
В случае такого разнесения - в случае ddos долбежки, не теряется производительно других шагов. Как следствие не страдают уже работающие пользователи.

[Maksim Herasim]

Достаточно сразу коннетиться к вебсокет, а на сервере разрешить только один коннект от телеграм id

Мне не очень нравится эта идея, т.к. в случае с зломышленниками, достаточно не сложно будет заняться перебором аккаунтов по ID. Поэтому сделан дополнительный ключ авторизации, который подтверждает что пользователь это тот пользователь, который изначально открыл приложение, а не который подменил WS данные в результате шаловливых ручек

[Everything_is_bad]

Maksim Herasim,

достаточно не сложно будет заняться перебором аккаунтов по ID

стандартного механизма авторизации будет достаточно, а всё остальное это оверинженеринг

[Maksim Herasim]

Everything_is_bad, Спасибо за Ваше мнение. Я не с точки зрения критики, а чтобы разобраться.
Предположим злоумышленник изучает как работает приложение и его внутренние механизмы. Очевидно что в консоли он не увидит POST/GET запросы, тогда начнет ковырять WS. Включит логирование сети, увидит события ws в котором передается session_id соединения, id пользователя . Что помешает поменять id пользователя на свой, таким образом закрыв сессию реальному пользователю и получив доступ к данным пользователя? Это можно будет сделать прямо в браузере в консоли, прописав небольшой js который будет осуществлять такую подмену. Или я чего то не понимаю?
Как основу я использовал статейку хабра, но вместо jwt использовал собственную реализацию access token.

[Everything_is_bad]

Maksim Herasim,

в котором передается session_id соединения, id пользователя . Что помешает поменять id пользователя на свой,

потому что session_id должен быть привязан к id пользователя, это как бы основы. По session_id сервер восстанавливает user_id. Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.

но вместо jwt использовал собственную реализацию access token.

а в jwt обычно прописывают user_id, поменять ты его не сможешь, токен будет невалидный

[Maksim Herasim]

Everything_is_bad,

потому что session_id должен быть привязан к id пользователя, это как бы основы. По session_id сервер восстанавливает user_id. Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.

Привязка на бэке есть. Ситуация в другом, в случае переподключения пользователя (закрыл-открыл, или refresh), сессия закрывает и открывается новая. Старая сессия на бэке удаляется, новая записывается. Даже если не будем всё время гонять по вебсокету id пользователя, как нам проверять валидность\легитимность данных от пользователя? По session_id, но это будет вторичный признак. Если произойдет закрытие\refresh
- session_id - меняется. В таком случае, предположим я злоумышленник - я делаю "event": "connect" и перебираю user_id.

небольшое отступление

Т.к. я допускаю что websocket сессия может зависнуть (ну отвалился интернет допустим), и не пришел "event":"disconnect", в таком случае лучше реализовать логику с перезаписью активной сессии. Пинг - понг реализован, чтобы закрывать неактивные сессии старше 2 минут. на самом деле немного сложнее, после подключения проверяем доступность по нарастающей - 10,15,20,40,60,120 сек

Получается что злоумышленник перебирая id сможет отключать пользователей, и переключать активную сессию на себя.
Просто смотрите, если я Вас правильно понял, то Вы имеете ввиду следующее:
После проверки initdata от ТГ и валидации user_id, создаем websocket соединения отправляя туда только user_id? Если я правильно понял Вашу задумку, в таком случае меня смущает что этот user_id ничем не защищен, и в случае перебора - пострадают пользователи, т.к. 1) их будет выкидывать из текущей сессии 2) данные от их аккаунта (в приложении) будут подгружаться туда, где их быть не должно. Или же Вы не дописали и подразумеваете дополнительные проверки?

а в jwt обычно прописывают user_id, поменять ты его не сможешь, токен будет невалидный

Да, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачу и получаю результат, как если бы я использовать jwt. В моем случае - все данные находятся в зашифрованном виде, и расшифровывать их может только бэк. В случае невозможности расшифровки - запрос отбрасывается на страницу авторизации. В случае даже гипотетического перехвата этого ключа, при попытке открыть /app - перекидывает на /one, т.к. в зашифрованном виде есть некий reload, который не позволит второй раз открыть страницу.
Не совсем понял -

Ну и сразу не нужно гонять session_id по вебсокету, его достаточно использовать в самом начале, при создании коннекта.

session_id создается по умолчанию в event connect и далее всегда передается от пользователя к серверу, ну точнее у меня в nodejs во всяком случае, всегда передается session_id, хотя в js на фронте - вообще не прописано его передавать. Т.е. в дебаге я всегда по умолчанию вижу session_id при любом типе сообщения websocket от клиента. Если имели ввиду user_id - тогда понял о чем Вы и полностью согласен.

[Everything_is_bad]

Старая сессия на бэке удаляется

зачем? но если удалил, то заново создай ее, у тебя есть initdata, то точно можешь подтвердить юзера, перебор user id тут не поможет

перебираю user_id.

почему вдруг перебор user_id должен на что-то влиять, почему вдруг знание user_id позволит подключиться под этим юзером?

Да, я знаю про jwt, в моём случае используя собственные знания - я еще более упростил эту задачу

не нужно упрощать jwt, нужно либо его использовать, либо нет.

[Maksim Herasim]

зачем?

А зачем мне хранить 2 сессии одного пользователя, когда задача стоит не допускать 2 одновременных сессии одного пользователя.

почему вдруг перебор user_id должен на что-то влият, почему вдруг знание user_id позволит подключиться под этим юзером?

Потому что для отрисовки страницы приложения я использую данные из websocket. Большинство данных получаются из ws. я не говорю про html/css/js, я говорю про данные условно - псевдоним, баланс, текущий счет, достижения.

не нужно упрощать jwt, нужно либо его использовать, либо нет.

Не использую. Использую своё решение, в котором хочу понять слабые места.

[Everything_is_bad]

Maksim Herasim,

Потому что для отрисовки страницы приложения я использую данные из websocket.

И что это меняет? Чтобы создать коннект к веб сокету, ты используешь сессию связанную с юзером, всё дальше твой сервер знает что этот коннект от этого юзера, не нужно гонять его id. Мне кажется у тебя вообще нет понимания как работают вебсокеты.

Использую своё решение

тебе равно использовать "свои решения", ты не понимаешь как общепринятые работают. Используй готовые стандартные реализации, тогда у тебя не будет проблем.

[Maksim Herasim]

Схема

1. Пользователь инициирует подключение к WS серверу и передает свой user_id
2. WS сервер отвечает и передает session_id подключения
3. Анонимный пользователь инициирует подключения к WS серверу, в котором передает ЛЮБОЙ user_id
4. Сервер отвечает присвоением другого id сессии.
Если мы передаем на WS сервер голые данные с user_id, как сервер должен отличить, пришли они от легитимного пользователя или анонима? Как WS сервер будет отличать авторизованного пользователя, от анонимного, который перебирает user_id ?
Я понял о чем вы пишите, что не нужно данные авторизации передавать в каждом запросе. Достаточно первично проверить что они валидные, и далее уже упираясь на session_id - мы проверяем легитимность запроса.
Мой вопрос в другом. Как используя ТОЛЬКО user_id мы будем защищены от перебора этого самого user_id ? Когда злоумышленник будет инициировать подключение к WS и подставлять случайные id ?
Т.е. речь идёт об инициации подключения, в которой на WS сервер мы передаем тот самый id пользователя из ТГ ?
Аналогично в http - сделать страницу в которой нужно ввести только свой логин (без пароля), далее у нас запишется кукиса по которой сайт будет считать меня username , и я буду прекрасно видеть все данные, который username оставил на странице. Правда в случае с кукисой пользователь может её изменить. В случае с session_id такой трюк не прокатит.

[Everything_is_bad]

Maksim Herasim,

Как используя ТОЛЬКО user_id мы будем защищены от перебора этого самого user_id ?

еще раз, почему вдруг ты сделал возможный что перебор user id дает подключится этому user id? только user_id и какие-то данные его идентифицирующие, только так.

Аналогично в http - сделать страницу в которой нужно ввести только свой логин (без пароля), далее у нас запишется кукиса по которой сайт будет считать меня username , и я буду прекрасно видеть все данные, который username оставил на странице.

зачем так делать?