Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 185
Блин, ну хз... Вы ожидали, что будут трекать браузер? Что-то мне подсказывает, что много есть сайтов, где можно вот так войти.
Фингерпринтинг хотите?)
Фингерпринтинг хотите?
Ви так говорите, как будто его там всё ещё нет.
Я ожидал, что буду иметь полный контроль над тем какие устройства подключены, а также могу рассчитывать на прозрачность их подключения.
Ожидал что для браузера будут использовать httpOnly куку, а токен будет работать временно. В случае XSS смогут увести только временный токен.
Насколько я понял, всё-таки не так много сайтов, где можно войти именно вот так, тем более мессенджеров. В WhatsApp, например, так просто не выйдет: ключи лежат в IndexedDB как non-extractable, отдельным значением их не скопировать. Перенести сессию можно только клонированием всей базы или профиля целиком, а это совсем другой уровень возни.
Правильно токен держать в HttpOnly-куке или вообще не отдавать в браузер (BFF). Тогда его не прочитает ни один скрипт на странице: ни XSS, ни левое расширение не утащат. Это и есть разница с localStorage, откуда токен достаёт любой JS. Фингерпринтинг для этого не нужен.
в whatsapp все очень сложно, там даже перенос переписки между девайсами - тот еще кейс.
да. как ни странно в этом смысле он самый защищенный.
Что-то, защищенный? Это решето на уровне by-design.
Вот мой реальный кейс, который я случайно воспроизвел. Есть смартфон, на нем установлен вотсапп. Им я не пользуюсь он лежит без дела с два года. Вставил в него новую симку вообще с кодом другой страны. За это время меня выкинуло из приложения и при запуске я вижу экран "Доброй пожаловать". Я ввожу новый номер, приходит смс и меня пускает в старое приложение, где вся переписка и чаты вообще от другого номера. Более того, вотсапп решил, что это мой теперь новый номер и в настройках профиля заменил старый номер на этот.
А я нигде и не выбирал сменить номер, обновить профиль, меня на телефоне встретил стартовый экран приложения, напомню. Даже если я вдруг слепошарый и как-то не заметил подпись о входе под другим номером, то как будто стоило на старый номер прислать код, смс или что-то в таком духе, а не просто так запускать в систему.
Ну сохранённые ключи он посчитал первичными. Раз у вас есть к ним физический доступ значит вы их владелец.
Это явно лучше чем первичная привязка к номеру.
А как это? Переписка же end-to-end шифруется, сервера вотсапа ее не хранят, есть только бэкапы на личном google drive.
Ну хранится же в телефоне в бд приложения, ну или google drive, учетка гугла та же самая.
В смысле так же самая? Вы же сказали, что это был чужой аккаунт. К нему привязана чужая учетка гугла, не ваша. Вы как-то получили доступ к чужому бэкапу, либо локальному (как?), либо к чужому гугловскоу облаку (как???). Либо вы что-то напутали.
По описанию, вацап решил привязку к телефону актуализировать. А приложение локально как стояло так и осталось стоять.
А как чужие переписки на телефон попали? Вотсап не может сам их на телефон загрузить, их нет на его серверах.
Смартфон на андроиде, учетка андроида одна и та же. Из приложения смартфона выкинуло на экран приветствия. Вошел в это же приложение введя другой, не связанный с изначальной учеткой ватсапом, номер. Меня авторизовало под старым акаунтом вотсапа с новым номером. На сколько это адекватно и правильно - решать Вам.
Все чаты, история и переписки на месте. Скорее всего, они хранятся локально, после нового входа в профиле сменился номер телефона на новый. Никаких дополнительных кодов, проверок и смс на старый номер не приходило.
Все верно, именно так и было. Знай, что будет такая дичь – записал бы видео. Сейчас искусственно хз как повторить, возможно принудительно разлогиниться в приложении и попробовать войти под каким-то другим номером.
Телефон он просил не для авторизации, а наоборот чтобы быть уверенным что это ваш номер т.к. он используется для идентификации. Т.е. он проверил не потеряли ли вы доступ к телефонному номеру.
А авторизует он вас по конкретному экземпляру установленного приложения. При необходимости можно еще пин/пароль поставить.
Я против привязки чего либо к телефонным номерам, но в рамках их дурацкой парадигмы привязки всего к телефону это логичное действие.
И это не имеет отношения к первоначальной теме о времени авторазлогинивания дополнительных сессий.
"не хранят" забыли в кавычки поставить
openai через перекупов так и покупается подписка))
Так просто, как в MAX, ни в один другой мессенджер не зайдёшь. В Telegram, например, не один токен, а несколько ключей (по дата-центрам), и лежат они вразнобой — собрать сложнее. В WhatsApp токен в таком виде вообще не хранится: ключи в IndexedDB, по отдельности не вытащить. А в MAX — одна строчка, 10 секунд работы. Для мессенджера, претендующего на цифровой ID… ну такое, как по мне.
Ерунду не пишите. Веб-версии у всех одинаковые, ничего нового ни в одном мессенджере не придумали (да и вообще ни в одной программе). Сервер не знает откуда вы посылаете данные - и будет их отрабатывать точно также. Попробуйте сами - зайдите в Телеге через веб-интерфейс и потом тем же способом скопируйте всё из localStorage - эффект будет тем же самым. Обычный токен жизни. Он и у OAuth также работает.
Не знаю, кто из вас пишет ерунду, но что-то с трудом верится, что в нормальных проектах jwt хранится в локалсторадже.
А какая в целом разница? Получить этот токен, хоть его куда распихай по браузеру вопрос одного скрипта, который уже выполняется у жертвы. Довольно провокационная статья, такая авторизация это база в очень многих проектах.
Вас наверное разработчики макса плюсуют
Спасибо, не видел этот гайд. Там всё подробно описано как нужно и как не нужно.
Правильно токены хранят не в localStorage: его читает любой скрипт, при XSS токен сразу утекает. Нормальный способ это HttpOnly + Secure + SameSite кука: JS её не прочитает, браузер сам подставляет, CSRF закрыт. Ещё вариант: короткий access-токен в памяти, refresh в той же httpOnly-куке с тихим обновлением. Самый чистый это BFF: токен вообще не отдают в браузер, он живёт на бэкенде, фронт ходит по httpOnly-сессии.
А в MAX токен лежит открытой строкой в localStorage. То самое, от чего гайд предупреждает.
Плюсанул. Раньше не особо задумывался. Но если это реально так просто (в смысле «сделать нормально»), то да, есть вопросики к «национальному мессенджеру»
Да я хз, тут на хабре какая-то секта хранителей токена в localStorage орудует. Не первый раз замечаю. Одни безапеляционно такую дичь несут, а другие их плюсуют :) Да, браузер небезопасное место для хранения сенситив данных.
Но одно дело положить деньги на стол, а другое в сейф. И так и так грабители обнесут, но во втором случае это будет сделать сложнее и займёт у них больше времени.
Есть токены которые просто не поместятся в куки. И если вы так не доверяете своему же фронту, что у вас возможен XSS, то утечка токена не самая большая ваша проблема.
Лимит размера у куки реальный, но это аргумент за то, чтобы не раздувать токен, а не за localStorage. XSS - это не про доверие своему фронту. Уязвимость прилетает через сотни сторонних зависимостей, аналитику, рекламу или скомпрометированный npm-пакет, и весь смысл httpOnly в том, чтобы токен нельзя было украсть даже при XSS, который вы не смогли предотвратить. А украденный токен это как раз большая проблема - в отличие от действий в моменте, его можно вынести наружу и использовать вне браузера жертвы, с другого устройства и после закрытия вкладки.
Пускать аналитику, а уж тем более РЕКЛАМУ на страницы, где есть секретные данные - это выше моего понимания :) Точно также как тянуть пакеты без проверки при каждом билде и без конкретной версии. В целом конечно да, вы правы, но иногда другого выхода нет (к примеру, API,которые просят класть токен в заголовок). Поэтому решаем проблему с XSS для начала, а потом уже всё равно как что хранить. Но это больше философский спор уже :)
Доооо, кражу кук из браузера так с девяносто лохматого года и не придумал никто)
Обычно такое в куках хранят ))
Если в телеге именно так, выходит что это не уязвимость, а стандарт индустрии.
По-моему, это уязвимость, либо бэкдор, т.к. хакеру украсть достаточно ключик, и без вашего ведома будут всё читать, даже сообщения слать.
И не понятно, зачем список устройств есть?
С другого устройства это не сработает. Речь о том, что на одном и том же компьютере неважно, какой программой открывать страницу.
можно копировать папку десктопной версии телеги на разные пк
с другой стороны, это удобная фича
Сервер вряд ли продолжит сессию на другой адрес. Разве только если оба компьютера сидят за одним NAT (или в одном VPN). Но работу из VPN вроде как Макс не одобряет.
Вопрос смены ip в рамках одной сессии - дискуссионный. С одной стороны, есть клиенты на мобильном интернете, перемещающиеся в пространстве, с другой стороны, есть системы детекции ботов, которые сигнализируют, что нас парсят/дидосят/что-то еще. Поэтому обычно используют разумный баланс.
Сессия десктопной телеги спокойно переживает переезд с одного адреса на другой. Берёте два компа/ноута, один подключен через стационарный провайдер, другой через мобильный (tethering например). Флешкой переносите телегу туда-сюда. Всё работает. Правда, я не пробовал запускать одновременно, как-то нужды не было.
дисклеймер: сей финт ушами я проводил пару лет назад, возможно сейчас это не сработает
интересно - попробуем.
зачем так сложно, просто включаете-выключаете квн. Ни телега (веб и десктоп), ни вацап (веб и десктоп) никак на это не реагируют. Ибо это смерть для людей на мобильном тырнете.
Я отвечал на этот комментарий, там речь шла не только о смене IP, но и о переносе с компа на комп.
Правда, я не пробовал запускать одновременно
я пробовал, работает
Я не писал что это уязвимость . Я дал инструкцию как это сделать ....ну и честно удивила простота . Я это случайно обнаружил когда делал форк рабочий . В статье нет провокации только ирония . Запомнить эти команды действительно сможет и бабушка и показать фокус соседке ))
Более того, можно копировать папку десктопной версии телеги на разные пк, отображаться будет, как одно подключение. Реально сидишь с кучи разных компов, хоть с флешки пускай, никаких паролей повторно не запрашивает.
попробовал - чуть сложнее , бабушка сразу не справиться но вы правы. вводим например это copy(JSON.stringify(Object.fromEntries(Object.entries(localStorage).filter(([k])=>/^dc(\d+_auth_key|\d+_server_salt)?
|^account\d+$/.test(k))))) , берем таким образом все ключи авторизации потом вот так их аккуратно вставляем const o=JSON.parse(prompt(‘вставь ключи Telegram’));for(const k in o)localStorage.setItem(k,o[k]);location.reload() (после вставляем ключи ). Но тут все таки пришлось повозиться . у телеграмм это не один ключ а связка MTProto-ключей. А что по поводу whatsup скажите ? как там войти ,я пока не смог .
А какой смысл в том, что в Telegram чуть сложнее? Для добросовестного использования, когда нужно перенести свою собственную сессию - это вредно. А недобровестный будет делать не руками, а скриптом, которому без разницы - один ключ или несколько.
Честно говоря, обманчивая псевдозащищённость Telegram'а и Whatsapp'а, на мой взгляд, это только хуже - вводит людей в заблуждение. Они разве что чуть-чуть безопасней Макса, но если с Максом люди ждут подвоха, то с этими бдительность теряется. По мне так чума на все эти дома.
А вся эта псевдобезопасность только мешает пилить свои кастомные клиенты (я вот навайбкодил себе немножко на Python'е благодаря необфусцированности протокола Макса; но, конечно, правильнее было бы, если бы они его открыли и опубликовали). Да и просто пользователям, чуть-чуть выбивающимся из привычной массы, может создавать неудобства.
(Впрочем, сами по себе вопросы по такой примитивной реализации хранения ключей в штуке, через которую подтверждаются Госуслуги, справедливые.)
max симку не блочил? на венде приложение ?
Тьфу-тьфу-тьфу, не блочил. Но вот реально боюсь, что благодаря подобным статьям рано или поздно заблочат. Поэтому использую очень аккуратно и ограниченно. Ну, пока ещё можно иметь несколько SIM-карт и несколько эккаунтов в Максе. Был бы открытый протокол - я был бы счастлив.
Я как раз хотел наработки свои показать сообществу обсудить . Думаете не стоит ? меня блокировали неоднократно но причину я нашел - решил .
Вы правы, стоит показать и обсудить. Я не очень удачно выразился. Я не имел в виду, что нужно молчать в тряпочку. Я подразумевал, что регулярное гыгыгыкань "а, какие лохи, а, какая тупая дыра" в отношении достаточно рядового недостатка (которым, как выяснилось, в целом обладает и Telegram) приведёт к избыточной реакции. Какой-нибудь начальник какому-нибудь менеджеру укажет на это гыгыгыканье, скажет исправить, и тот организует исправление с большим запасом, закрыв, обфусцировав, поставив микроскопические таймауты и параноидальное отслеживание фингерпринтов, которые будут создавать кучу проблем пользователям, но зато себя этот менеджер на будущее прикроет полностью, и начальнику отчитается.
Но к Вас у меня претензий нет. Вы правильно написали, и тон в статье выдержали корректный. Я за то, чтобы делиться информацией и обсуждать. Спасибо!
А вся эта псевдобезопасность только мешает пилить свои кастомные клиенты
...
но, конечно, правильнее было бы, если бы они его открыли и опубликовали
А потом злые люди убалтают жертву поставить костомный клиент с недокументированными особенностями. Учитывая, куда этот MAX тянут - последствия могут быть сильно неприятными. Это, конечно, удручает, но иногда отсутствие возможности написать альтернативу - скорее полезно, чем вредно.
Коллега, Вы о чём? Злым людям открытый протокол ничем не поможет - закрытый протокол уже неоднократно отреверсен, и даже кастомные клиенты какие-никакие тоже есть. Просто добровестное использование по лезвию бритвы ходит, потому что как справедливо написали выше, Макс в любой момент может забанить использовательзующих неофициальные клиенты, это грустно. А вот у злых людей такой проблемы нет - им пользователей не жалко, у них задача одноразовая, вытянуть из "пользователя" всё, что можно, и кинуть.
Это не то место, где работает security through obscurity.
Коллега, Вы о чём?
В том смысле, что само знание "альтернативных клиентов нет и не будет" - немного останавливает от установки того, что злые люди предлагают поставить, особенно если социальной рекламой долбить.
А если протокол опубликован и несколько альтернативных клиентов как-то эксплуатируются --- то убалтать поставить еще один "вот этот точно самый удобный" заметно легче.
Так что увы, открытый протокол и существование этих самых альтернативных клиентов - злым людям именно помогает. Насколько сильно - вопрос, но помогает.
Вот чиновники такими совершенно ничем не обоснованными рассуждениями и руководствуются - "как бы чего не вышло". Вообще никак не останавливает от установки и уболтать не легче. Те, кто попадается на разводки, не облают знанием о том, могут ли быть альтернативные клиенты или нет.
Сами прикиньте - у Телеги есть альтернативные клиенты давно, они вполне легальны и Телега их разрешает. Как Вы сами-то думаете, среди тех, кто достаточно компетентен, чтобы поставить себе альтернативного клиента, во сколько раз меньше процент попавшихся на удочку мошенников по сравнению с общей массой?
А то, что Вы, похоже, думаете, что альтернативных клиентов быть не может, и пытаетесь строить на этом безопасность - это ухудшает, а не улучшает ситуацию. Это только увеличивает уязвимость людей, которым даже вдалбливаемое из каждого утюга "никому не сообщайте коды, приходящие по SMS" не мешает эти коды сообщать. Ваше "решение" - это ложная видимость решения, при том что очень многие полезные способы использования оно сильно затрудняет. Приходится шлагбауму, например, приделывать несколько разных протоколов связи - один на случай введения белых списков, другой на случай, если Макс забанит SIM-карту и т.п.
Даже если вы пропечатаете в подкорке всех жертв, что альтернативные клиенты используют только мошенники, настоящие мошенники просто назовут то же самое не альтернативным клиентом, а просто более новой более совершенной самой что ни на есть официальной версией, имеющей нужный "для расследования", "для удобного сообщения показаний счётчиков" или ещё для чего-нибудь функционал.
Те, кто попадается на разводки, не облают знанием о том, могут ли быть альтернативные клиенты или нет.
Попадаются абсолютно все, только в разной степени. Это разновидность фишинга.
И именно вот с такими вот приложениями вроде Госуслуг, банковских - качели немного в другую сторону качаются. Неприятно, да, но как иначе защищаться - совершенно непонятно. 'Мы облегчаем создание альтернатив, опубликовав код, но сам дурак, если неофициальный клиент поставил а он что-то плохое сделал' - это не совсем хорошее решение.
Сами прикиньте - у Телеги есть альтернативные клиенты давно, они вполне легальны и Телега их разрешает. Как Вы сами-то думаете, среди тех, кто достаточно компетентен, чтобы поставить себе альтернативного клиента, во сколько раз меньше процент попавшихся на удочку мошенников по сравнению с общей массой?
Телега не дает всех тех возможностей, что дают приложения банков, госуслуг и которые вот-вот будет давать MAX.
Попадаются абсолютно все, только в разной степени.
Во-первых - нет, не все. Только малая часть из сталкивавшихся с фишингом, попадались на него.
Во-вторых - это критически важно, что в разной степени. Если компетентность человека позволяет видеть фишинг, то и в предложении поставить ещё один альтернативный клиент он фальшь увидит.
Раз влияние поддержки альтернативных клиентов статистически не значимо, то нет никакого смысла существенно уменьшать полезность продукта для пользователей ради "купирования" высосанной из пальца опасности. Ну, единственно, конечно, есть смысл для какого-нибудь чиновника/менеджера, конечно, который может отчитаться, как он геройски защитил граждан, закрыв своей грудью амбразуру стррррашную уязвимость, а можно даже в прессе побить себя кулаком по груди.
Неприятно, да, но как иначе защищаться - совершенно непонятно.
Что тут непонятного? Всё предельно понятно. Даже если принять на веру, будто нельзя столь чувствительные данные отдавать в альтернативные клиенты (а это не так - на самом деле можно, но пусть), можно банально предусмотреть в протоколе ответ сервера "данная информация не отдаётся неофициальным клиентам, пожалуйста, воспользуйтесь для её просмотра официальным клиентом", вот и всё.
Непосредственный доступ к самой чувствительной информации в большинстве случаев не нужен. А вот легальный и документированный доступ к обычной информации ("телеграммного" уровня), а также к уведомлениям о том, что пришла чувствительная информация, для которой надо лезть в официальный клиент - ещё как нужен. Чтобы делать шлагбаумы или там индикаторы на Ардуинке.
Безопасность по сравнению с попыткой полного запрета увеличится, потому что уменьшится количество людей, мотивированных на обход запрета - и, соответственно, количество разбирающихся в том, как запрет обойти.
Даже если принять на веру, будто нельзя столь чувствительные данные отдавать в альтернативные клиенты (а это не так - на самом деле можно, но пусть),
Аргумент не совсем в этом. В нормальный альтернативный - действительно, ничего страшного. Аргумент в том, что с учетом предполагаемых возможностей - инициатива злодеев сделать и всучить жертвам альтернативный клиент с злодейским функционалом - резко увеличивается.
А вот легальный и документированный доступ к обычной информации ("телеграммного" уровня), а также к уведомлениям о том, что пришла чувствительная информация, для которой надо лезть в официальный клиент - ещё как нужен.
Вот если идет речь только о 'бытовой' части протокола - я буду за.
Но я сильно сомневаюсь, что чисто 'бытовая' часть настолько хорошо разделено и что отправить/получить сообщение от шлагбаума и отправить сообщение в учреждение или получить из банка(помним про желание отправлять защитные коды банков именно в MAX?) -- как-то существенно отличаются.
Чтобы делать шлагбаумы или там индикаторы на Ардуинке.
У меня другое восприятие. Делать вот это все в MAX - ну, несколько странно. Как и использование его в качестве 'бытового мессенджера'.
Я рассматриваю его именно как госмесседжер для общения со всем тем офицозом, что там государства имеется. Приложение-компаньон для госуслуг. Отсюда и позиция 'никаких сторонних клиентов'.
Ну да, они сами зачем-то тянут в сторону 'бытового', но это они зря и, надеюсь, одумаются.
Аргумент не совсем в этом. В нормальный альтернативный - действительно, ничего страшного.
Коллега, именно в этом. Я просто не хочу растекаться по древу и расписывать сценарии, как можно достаточно достаточно безопасно и довольно удобно для всех организовать, надо просто захотеть это сделать и чуть-чуть подумать...
У меня другое восприятие. Делать вот это все в MAX - ну, несколько странно.
Нет, не странно. Просто Вы, по-моему, немного поверхностно смотрите, потому что не задумывались об этой стороне вопроса.
Вы хотите, чтобы у Вас связь с оборудованным камерой шлагбаумом или датчиком проникновения работала, когда включены "белые списки"? Ну, или, там, зимой перед выездом на дачу включить отопление, чтобы приехать не в холод? Не хотите? А большинство - хотят.
Вы не хотите иметь возможность прочитать на обычных устройствах (а не специально выделенном для Макса) уведомление о том, что завтра - какое-нибудь там собрание родительского комитета? А многие люди хотят иметь такую возможность.
Вы не хотите, чтобы у вас на десктопе или на "Ардуинке" крутилась программа, которая отсортировывала бы по нужным вам сложным критериям важные и неважные сообщения, приходящие в Макс от коллеги/друзья и писала бы ненавязчиво о важных? А я вот хочу.
И нет, идея, что если коллеги/друзья/родительский комитет пользуются Максом, то надо с ними порвать или заставить всех перейти на какой-нибудь Bip - это плохая идея, она очень плохо работает.
Я не хочу зависеть от официального клиента Макса на своём основном оборудовании, но при этом не хочу в ряде случаев пропустить сообщения.
Нет, не странно. Просто Вы, по-моему, немного поверхностно смотрите, потому что не задумывались об этой стороне вопроса.
Возможно. Но смотрим на Федеральный закон от 24.06.2025 N 156-ФЗ. Про 'Многофункциональный сервис обмена информацией'. Читаем. Там 'телеграмное' общение между людьми вообще даже не рассматривается, если я правильно читаю. А есть достаточно длинный список государственно-официальных вида
информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг и исполнения государственных и муниципальных функций в электронной форме
и
подпись документов при помощи ЭП
А MAX именно этой штукой назначили(Распоряжение Правительства Российской Федерации от 12.07.2025 № 1880-р). Так что да, именно как сервис для всего этого официоза и я его и воспринимаю. А то что они делают, пытаясь стать 'бытовым' - это что-то непонятное и непонятно, с какой стати.
Коллега, мы же обсуждаем реальный Макс и реальные потребности людей. Если Вам, исходя из прочтения каких-то официальных документов кажется, будто Макс не используется в первую очередь как аналог Телеграма и Whatsapp'а, а у людей нет потребности в клиентах, отличных от официального - простите, Вы очень сильно ошибаетесь. А Ваше личное отношение к Максу, и для чего его использовать будете лично Вы - право слово, это Ваше личное дело - реальность Вы этим не измените.
убалтают жертву поставить костомный клиент
Что мешает уболтать на официальном клиенте нажать Ctrl + Shift + J, ввести в открывшееся окно нужный код и продиктовать появившийся токен?
То есть официальность клиента - не гарантия безопасности. Ведь в кастомной версии разработчик может тщательней подходить к реализации скользких моментов, которые сочтёт важными, в то время как официальная команда их проигнорирует в силу текучки дел внутри компании.
А потом злые люди убалтают жертву поставить костомный клиент
Ну будут убалтывать поставить "еще более официальный клиент". Или "безопасный клиент".
Нажмите
Ctrl + Shift + J. Откроется чёрное окно консоли.
У вас ошибка. Не черное, а белое окно.
А если говорить серьезно, это же ничем не отличается от сессионной куки, которую можно скопировать не то, чтобы в другой браузер, можно ваще в HttpClient подсунуть и использовать в свое удовольствие, пока она не просрочится на стороне сервера.
А мне вот интересно: если держать сессию только в браузере (выключив макс на материнском смартфоне) - сколько такая сессия проживет? Где-то в глубинах кода приписан срок протухания токена?
это не связанные сессии - на смартфоне и токен из браузера . на смартфоне можно выйти это никак не повлияет на токен из браузера ( сессии разные ).По времени думаю не ограничено ( нужно проверить ).
на смартфоне можно выйти это никак не повлияет на токен из браузера
Это понятно (и уже проверено :)).
Вопрос в продолжительности сольной работы веб-версии.
У вацапа например ограничены. Пару недель вроде.
Это гениально, право слово! Вот это та самая видимость безопасности, от которой только хуже. Мошенник не будет ждать две недели, чтобы сделать свои чёрные дела.
В большинстве сценариев мошенничества такое "ограничение" - это мёртвому припарка... (От продолжительного чтения переписки посторонним может помочь, но здесь бы гораздо больше помогло бы обнаружение таких пассивно читающих устройств и уведомление об этом пользователя.)
У меня чёрное.)) Тему в DevTools меняют через F1, так что у всех по-разному ты прав, в статье формулировку поправлю.
По куке: тут и не кука. У MAX вход лежит строкой в localStorage берёшь её из консоли и вставляешь в другой браузер, входит. Куку, если она HttpOnly, из консоли так просто не вытащишь, видно только во вкладке хранилища. А эта строка лежит открыто и копируется одной командой. Так что не «как кука», а доступнее. ну и это мессенджер все таки как я уже сказал претендует на цифровой id . c whatsup или телегой такой фокус бы не удался. суть то в том что это сделать просто .
>>Куку, если она HttpOnly, из консоли так просто не вытащишь
document.cookie
document.cookie не возвращает cookie с флагом HttpOnly - это и есть смысл флага.
У вас ошибка. Не черное, а белое окно.
У кого белое — а у кого чёрное, бвана!
Тут новости пролетели:
MAX пропал из Google Play — пользователи сообщают, что мессенджер больше не отображается в магазине приложений во всех регионах.
Давай досвиданья!
Проверил - действительно нет ....весело . Но с андройд проще есть сторонним магазины и возможность установить на прямую apk. Вот с ios сложнее . Кстати на днях выложу форк для ios . Тестирую пока все работает . Через тест флайт можно будет установить или себе залить и пересобрать свой max . .. если он вообще кому нибудь нужен ещё .
У меня отображается и скачивается
Пишу из рандомного региона - макс на месте.
Может потому что Max стал Макс? у меня в гугл плей есть
Никуда не пропал, вроде.
К сожалению, рано обрадовались... Пишут, что они исчез из всех регионов, кроме этого...
Макс никогда не ставил.
Сейчас проверил из своего забугорья - в гугл плей макс присутствует, в самсунговском сторе тоже в наличии.
Сложно удержаться
Я так смотрю что наступил момент смирения. Статьи про эту дрянь перестали набирать минусов. Все по советскому анекдоту
“третий секретарь райкома”: - завтра повесят каждого 10-го
“голос из зала”: - веревку свою принести или профком обеспечит?
В чем ваше беспокойство? Срок действия токена наверняка короткий, так что если ваш токен как-то украдут, через некоторое время Макс перестанет его принимать. Если нет refresh-токенов.
А рефреш токен тоже в локал-стородже, шучу. Вообще использовать рефреш токен на сайте - не очень правильно. Тут лучше кука подходит.
Многие неправильно понимают access/refresh token
Для аутентификации:
1. Пользовательно должен отсылать: логин, пароль и идентификатор устройста
2. Бекенд должен сохранить запись: id пользователя, идентификатор устройста, хеш refresh токена
3. Бекенд должен вернуть access/refresh токены с разным временем жизни, access < refresh
Время жизни access должно быть минимально, время жизни refresh задает через какое время неактивности надо заново аутентифицироваться. При приближении или истечении жизни access, клиент должен послать refresh token и получить новую связку, при этом старый refresh token должен инвалидироваться.
В случае компроментации access/refresh токенов, при попытке обновить токены злоумышленником, жертву должно выкинуть после истечения access токена, при повторной аутентификации все токены для идентификатора устройста должны инвалидироваться, что уже в свою очередь выкинет злоумышленника, либо на другом устройстве можно вручную вырубить скомпроментированнное устройство.
Задача refresh token не дать использовать постояно клон сессии устройства. Идентификатор устройста для веб версии может быть случайно сгенерен один раз.
Это же вариант для приложения, там рефреш - норм. А вот если в браузере, то рефреш никак не защитить: всё что можно передать из js будет повторено нападающим.
Можно привязяться к TLS-сессии, но это до первого сброса соединения
В предыдущем комментарии я и описал как должно работать в том числе в браузере, разница только в получении идентификатора девайса, для браузера это будет скорее айди сессии, если злоумышленник получает доступ к системе, нет разницы, стащить куки/localStorage/indexeddb браузеров или данные приложения, разделение аксес и рефреш не защает от кражи доступа, этот подход минимизирует время использования этого доступа, даже в случае кражи рефреш токена, как писали в других тредах, от js защищают http-only cookie, access при этом ставится только для пути с апи, а рефреш только для одного метода апи с обновлением, защита токенов на клиенте и обработка на бекенде долняют друг друга, а не выбор что лучше.
если злоумышленник получает доступ к системе, нет разницы, стащить куки/localStorage/indexeddb браузеров или данные приложения
Согласен
рефреш только для одного метода апи с обновлением, защита токенов на клиенте и обработка на бекенде долняют друг друга
Вот тут не согласен. Если делать в лоб, то по стандарту OpenID рефреш токен и ацесс токен возвращаются вместе. Значит оба хранятся в браузере и в случае xss утекают тоже оба. Поэтому так не делают.
Я знаю 2 решения:
Настроить у своего идентити провайдера отдельного клиента для вэба, который хранить авторизацию в куке, а офлан доступ (рефреш токен) запрещает.
Поставить BFF, который будет получать токены и превращать один из них в куку
минимизирует время использования этого доступа, даже в случае кражи рефреш токена
Видимо тут затык, как это можно минизировать доступ в случае кражи рефреш токена? Я думал, что тут только отключение сессии помогут и какие-то эвристики, что по одному токену из двух мест ходим.
Так это же обычный угон куки получается (Cookie Hijacking / Session Hijacking). Таким образом можно красть авторизованную сессию от любого сайта. Авторизовались на одном компе, скопировали с него куки на другой комп и сайт считает, что на втором компе вы тоже авторизованы, хотя никакие логины и пароли вы там не вводили.
Как минимум ещё адрес должен совпасть.
Это немного не так работает. Обычно выдаётся короткоживующий токен, очень часто JWT, где прописан срок протухания. Пока он жив, ты можешь обращаться к сервису. Срок его жизни может быть и пол часа и час. Когда токен протухает, в ход идёт рефреш токен, который можно хранить уже в Cookie, которые недоступны из JS, а значит его через JS уже не угнать, только лезть в кишки баузера, а потом также через кишки вставлять эту cookie в другой браузер. Так что угон этой cookie даст тебе доступ к сайту максимум на час, если, конечно, разработчики не идиоты и не выставили время жизни access токена на большой срок. Через час токен протухнет и старый браузер обновит его, а новый браузер обломается, поэтому что у него нет refresh токена.
Жаль автор не глянул хотя бы через jwt.io что там внутри токена. Если это был обычный JWT, то там должна быть информация, когда токен протухает. Если время протухания далеко в будущем, то это точно будет фейл.
Глянул на jwt.io, как советовал. Но главное даже не там. Токен это один сегмент, без точек. У JWT их три через точку (header.payload.signature), так что это вообще не JWT, разбирать нечего. jwt.io это подтвердил: Decoded Header и Payload пустые.
Раз структуры нет, то и читаемого exp в строке нет. Значит срок держит сервер, в самом токене его не видно.
Да. Токен вполне может быть и рандомной строкой. Сервер сам решает когда токен протух. Тогда интересно, сколько времени проживёт токен. Я бы не давал много времени токенам, что лежат в localStorage. Сам таким пользуюсь, время жизни - пол часа. Если просто украдут, то время на совершение действий не больше этого времени. Дальше надо снова токен добывать, т.е. нужно контролировать устройство всё время. Эта заметка навела меня на мысль переделать всё на httpOnly cookies. Раньше не знал как сделать, а сейчас нашёл.
Если бы был jwt, из него можно было бы извлечь информацию, но тоже не всегда (иногда контент шиыруют, например, ЕСИА). А сервер может проверить валидность такого токена по закрытому ключу. Здесь не так.
Тут 2 стула: если токен, то могут увести с помощью xss, если кука, то можно влететь на межсайтовую подделку запросов.
Я решил собрать грабли из двух миров: короткоживущий токен для доступа к апи, и долгоживущая http-only кука для выпуска токена.
Плюс политики работы с контентом, чтобы снизить вероятность XSS (запрет inline-скриптов и т.д.) и другие полезные заголовки, которые можно проверить здесь: https://developer.mozilla.org/en-US/observatory/analyze?host=habr.com
У меня, кстати 105 из 100
Подождите, за 30 лет браузеров механизма надежного приколачивания сессии к конкретному устройству без возможности работы после переноса не сделали? Копирование кук, профилей, клонирование ОС целиком чтобы ломалось о HWID, но так чтобы этот HWID не был доступен владельцу сайта и не давал однозначно идентифицировать.
Может я хочу что-то нереализуемое....
Подождите, за 30 лет браузеров механизма надежного приколачивания сессии к конкретному устройству без возможности работы после переноса не сделали?
Условно сделали. mTLS с неизвлекаемым клиентским сертификатом в аппаратном кейсторе. Там вообще все может без всяких сессионых cookes работать - сразу из данных соединения извлекаем, кто тут к нам цепляется. Только кто же им пользуется-то?
тут с другой стороны деанон и слежка за пользователями если этим начнет какаянибудь метрика и вообще кто попало пользоваться. кое где в приличных странах это криминал уже.
При этом, всё софтовое можно эмулировать.
Похоже школьники писали авторизацию, надо было использовать OAuth2.0-PKCE или еще добавить клиентскую подпись, и ключ создавать с запретом экспорта их криптохранилища
Это важное замечание. Т.е. если "а это у всех так и ничо" потому что не заморачиваются, то подсвечивать "школьниковость" важно и нужно. Иначе в соседнем треде "ачотакова жили без HTTPS и ничо".
Есть рабочие полноценнные механизмы защиты? Надо внедрять. Есть проблемы с совместимостью защиты? Надо решать.
Но работа под своей учёткой в Windows - уже считается Trusted. Если вы не можете доверять учётной записи под которой сидите, то как вообще вы собираетесь хранить ключи, пароли, хэши и тому подобное?
Местные на самом деле должны со слезами на глазах благодарить РКН: столько зонтичных инфоповодов дали для дешевого (зачастую и нейрослопового) хайпа: макс, впн, блокировки... Карму набить в таких условиях просто как переслать пакет по I2C
как вообще вы собираетесь хранить ключи, пароли, хэши и тому подобное?
Где-то там
Интересует может ли сторонний сайт этот токен как-то выцыганить. Подозреваю, что нет. Если так, что дыра невеликая. Ибо если у вас злоумышленник уже сидит за компом и копается в вашем браузере, то у вас заметно большие проблемы, чем безопасность мессенджера.
Плюс я свой макс не привязывал ни к каким госуслугам и т.п. Ибо нефиг.
Хороший вопрос - я проверю на сколько легко .пока речь шла о том что достаточно 10 сек доступа физически к пк и токен ваш. (повторюсь так просто с др мессенджерами не работает) .
За несколько секунд можно и профиль браузера утащить, а это точно сработает с другими мессенджерами (и не только с ними). Или трояна воткнуть.
Так что тут всё же защита от удалённого доступа важнее. Если она есть, то это дырка вида "хакер с отвёрткой может выкрутить ваш жесткий диск". А вот если чужой сайт может в это хранилище залезть...
Ещё вопрос - можно ли этот токен на другой комп утащить?
За 10 секунд набить js скрипт и запомнить строку с ключом :)
С физическим доступом к компьютеру HTTP-only cookie точно так же копируется и потом используется для разных интересных запросов (которые например меняют пароль, способ аутентификации или ещё чего). Если токен короткоживущий, то с этого аспекта разницы никакой особенной нет
Сторонний сайт - возможно нет. А что насчет расширений с правами на content injection на * ? есть такие, где это надо по вполне легитимным причинам но одна дыра (или, раз уж Макс это (как заявляют) типа официальный госмесенджер который (согласно рекламе) ловит в любых лифтах(в том числе видимо в лифтах бункера Ямантау)) то нужно было позаботится о защите потому что могут в ход пойти совсем интересные атаки на расширения (особенно учитывая что большинство авторов этих расширений - тоже не из России).
Ну это тоже уровня троянов угрозы, то есть у злоумышленника есть доступ к браузеру/компьютеру.
Я не говорю, что на эту дыру можно внимания не обращать. Просто интересны векторы атаки кроме как "запустил девтулс и вытащил токен".
Да, похоже реально. Расширение с content-script на всех урлах видит localStorage страницы, значит __oneme_auth прочитает и сольёт, сразу у всех своих юзеров. Это серьёзнее стороннего сайта: сайт не достанет из-за cross-origin, а расширение достанет.
Но похоже , к Telegram это применимо так же: он тоже держит ключи сессии в localStorage, то же расширение их прочитает. Разница только в том, что у MAX один bearer-токен, а у TG связка ключей, для скрипта без разницы. Устойчивее всех WhatsApp: ключи в IndexedDB non-extractable, сырой ключ скрипт не выгрузит.
Вектор общий, но спрос именно к MAX выше: его продают как защищённый госмессенджер под цифровой ID. От такого ждёшь, что сессия не будет валяться в localStorage.
Интересно, если открыть и закрыть вкладку в инкогнито - токен удалится?
ИМХО, для данного мессенджера, на который смотрят миллионы глаз и большинство с критикой, надо было более тщательно продумывать процесс, а не хранить, как у обычных низкокритичных web-приложений, секретный токен в localStorage. Есть посложнее методики и протоколы auth для такого всё же.
Смею разочаровать автора, он "раскрыл" то, что является базовым принципом: Whoever bears the token is treated as the authenticated user. Буквально на уровне утверждения о уязвимости замка двери типа "я сделал дубликат ключа, а он открывает дверь".
Что же, ждём "взлом" остальных 95% процентов сайтов и API в интернете (этим же способом).
Вроде бы всё в лучших практиках описано, но ведь у разработчиков другие приоритеты, правда ведь?
Хранить токен в httpOnly Secure SameSite cookie вместо localStorage. Привязывать сессию к fingerprint браузера (User-Agent + IP + часовой пояс). Отслеживать смену геолокации/IP внутри одной сессии, при подозрении — сбрасывать токен. Использовать короткоживущий access-токен + отдельный refresh-токен с одноразовой ротацией. Показывать пользователю список активных сессий с возможностью принудительно завершать. Добавить Content Security Policy: script-src ‘self’ — усложнит выполнение стороннего кода. Требовать подтверждение через email/SMS/QR при входе с нового устройства. Инвалидировать токен при нажатии «Выйти» на серверной стороне, а не только на клиенте.
если у атакующего есть доступ к консоли жертвы, всё вышеперечисленное поможет примерно никак. А вот геморроя легальным юзерам, например, с квн и/или мобильным интернетом, создаст выше крыши.
Игра в безопасность — она такая. Делаешь юзерам удобнее — становится уязвимым для большых вариантов атаки, делаешь безопасным — либо пользователи взвоют, либо просто мало кто будет пользоваться твоим продуктом.
С моей точки зрения клиенты маха — такие же, как и у других клиентов других мессенджеров. Все могут допускать ошибки и ставить удобство в ущерб безопасности. Но нужно не забывать, что в случае с мах, дьявол кроется на серверной стороне.
>>Отслеживать смену геолокации/IP внутри одной сессии
Это у кого такое реализовано прям интересно? То есть я вошёл в приложение в Минске, сел на самолет, прилетел в Москву и всё, бросаем сессию? Зачем?
Решение должно приниматься не в лоб, а на основе совокупности факторов. Из Минска в Москву за 15-20 минут не попасть (только через VPN). Да и тут речь только про веб-интерфейс.
Москва Минск пример неудачный. А вот "моб.связь - вайфай - опять мобильная связь" просто типовой набор посетителя вебресурса, который иногда выходит из дома.
У меня один друг в Нидерланды за секунды попадает.
Передвигаясь по москве можо телепортироваться куда угодно за секунды. Кроме того какой дурак скаму даст геолокацию, тем более в браузере?
В заголовке не хватает слов ШОК и СЕНСАЦИЯ!!!
А если серьёзно, то при наличии доступа к отладочным инструментам на доноре не спасут ни куки, ни смс коды, ни 2фа через totp. Всё спокойно переносится на другой комп стандартными средствами отладки. Единственная реальная защита это либо нормальный электронный ключ с неизвлекаемыми аппаратными ключами, либо скрэтч-карта с одноразовыми кодами. Но как правило гении её сразу полностью стирают и сканируют.
Так что, если вы какой-нибудь директор или просто небедный человек и хотите защитить свои госуслуги, то только рутокен на отдельном, лежащем в сейфе ноутбуке.
Для таких случаев делают обновление токена. Просто не всем нужно настолько заморачиваться
Нет у менян был вариант "Скандалы интриги расследования , показать все что за кадром все что скрыто", но вспомнил , что это хабр и так минусов наставят полный вагон - не стал обострять .А если серьезно то суть то не сценарии когда чужой дядя за твоим ноутом, а расширение или XSS, которые читают localStorage у всех разом и удалённо. Вот тут HttpOnly как раз работает: куку скрипт не прочитает, а голую строку из localStorage прочитает запросто. Так что «нифига не спасёт» это только про случай, когда машину ты уже физически отдал.
Даже с "физически отдал" - может все делать физически только на этом устройстве или легко воспроизвести потом на любом другом и пользоваться достаточное время, если доступ физически утерян?
Аналогия - разблокированный смарт попал в руки. Можно что-то делать в незаблокированных приложениях, но так чтобы прямо забрать все и элементарно входить на любом устройстве (код-пароль, отпечаток, faceID, ввод пароля) - такого быть не должно.
Именно, напихать полезную нагрузку на расширение (например, сделать какой нибудь обход блокировки, народ подтянется) и забрать local storage. А если токен ещё и действует долго, вообще красота. Вроде как коды подтверждения половины платформ, связанных с Госуслугами, на макс приходят
ну на самом деле это конечно баг браузера и его хоста расширений. А чё доступ сразу к паролям от всех сайтов не дают?
Понимаю про плагины для разработчиков, но один раз спросить "расширение х хочет локалсторадж сайта у" вполне можно.
И чо?
Честно угнанные куки работают много где. Тот же ВК кажется ровно тем же макаром работал всегда и одно время была огоромная проблема из-за того что фишинговые сайты сразу эту куку угоняли.
Ого, вот это метод, таким же способом не ломаются 99% сайтов
Вам бы в статье больше упор сделать на вектор атаки (XSS, зловредные экстеншены), а не на то, как открыть консоль браузера. Тогда статья будет понятнее и полезнее.
А то сейчас выглядит реально, как мегановость от школьника, который узнал про существование DevTools, а реальную проблему никто не видит.
Познавательно и пугающе одновременно.
По делу: проблема не в том, что токен можно украсть из localStorage. Проблема в том, что MAX (и многие другие сервисы) вообще хранят валидный токен в открытом виде в "локалсторедж".
Правильный подход — httpOnly cookie с флагом Secure + SameSite=Strict. Тогда даже если вы скопируете весь localStorage — ничего не зайдёт.
Что делать обычному пользователю: выходить из аккаунта на чужих компах кнопкой «Выйти», а не просто закрывать вкладку. И не оставлять браузер без присмотра.
P.S. За дисклеймер про «делайте только со своим аккаунтом» — жирный плюс.
Многие об этом забывают.
Спасибо .Коротко и все по делу . Дискуссию можно закрывать.
если кто то получил доступ к вашему устройству, то разницы нет, какая система защиты у сервисов
Тихо тихо тихо, контору не палите)
А то запретят и отвалится мой бот, который школьные чаты из Скама в ТГ перекидывает!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как войти в MAX без пароля, СМС и QR. Две команды, и ты внутри