Stfw.Ru
В мессенджере Max изображения открываются по прямым URL даже без авторизации, и это, по методикам ФСТЭК и CVSS, тянет на серьёзную уязвимость контроля доступа, передаёт stfw.ru.
Вокруг российского нацмессенджера Max разгорелся полноценный кейс по информационной безопасности: пользователи и специалисты обнаружили, что отправленные в личных чатах и каналах изображения получают прямые URL и открываются без авторизации, а ссылки и сами файлы остаются доступными даже после удаления сообщения в клиенте.
Как работает доступ к фото по ссылке в Max
Суть проблемы в Max проста до безобразия: при отправке любой картинки мессенджер генерирует статический URL, который ведёт напрямую на файловое хранилище сервиса. Открыть этот адрес можно из любого браузера, без входа в аккаунт и без каких‑либо дополнительных проверок прав доступа на стороне сервера. Более того, удаление изображения из переписки не приводит к физическому удалению файла с сервера — ссылка продолжает работать, и контент остаётся доступным всем, кто ею обладает.
Дополнительный тревожный момент — часть структуры URL одинакова для всех файлов конкретного пользователя: внутри ссылки присутствуют блоки, кодирующие идентификатор картинки и идентификатор пользователя. Это означает, что, зная один валидный адрес и схему построения URL, злоумышленник теоретически получает возможность массово перебирать варианты и собирать целые галереи чужих изображений. Именно такой сценарий и был продемонстрирован сообществом: в сети уже появились подборки ссылок и архивы с файлами, попавшими в публичный доступ через Max.
Что именно закодировано в ссылке
В примере с ресурсом вида i.oneme.ru/i?r=... внутри параметра r используется строка, напоминающая base64‑представление составной структуры. Исходный анализ указывает, что в этой записи содержится как минимум три поля: некий заголовок служебного назначения, идентификатор изображения и идентификатор пользователя (или чата). Для идентификатора картинки и пользователя выделено по 128 бит, чего более чем достаточно, чтобы при нормальной архитектуре сделать перебор практически нереалистичным.
Однако сама по себе большая длина и энтропия ссылки не решает проблему, если сервер вообще не проверяет, кто именно обращается к этому ресурсу. В итоге схема «секретный, но общедоступный URL» превращает приватный контент в объект, защищённый только неизвестностью адреса, а не полноценной системой контроля доступа. Такое решение может быть приемлемо для однократного шаринга файлов наподобие публичных облачных ссылок, но оно выглядит крайне сомнительно для личной переписки в национальном мессенджере.
Две модели угроз: открытый URL и утёкший URL
Для честной оценки ситуации авторы технического разбора разделяют два принципиально разных сценария угрозы. Первый — когда любой человек, узнавший прямой URL (например, вытащенный из кода веб‑версии или полученный иным способом), может открыть фото без авторизации. Второй — когда доступ возможен только в том случае, если URL уже каким‑то образом скомпрометирован: его переслали, подсмотрели в логах, зафиксировали на скриншоте и так далее. На бумаге во втором случае риск ниже, поскольку противник должен сначала завладеть ссылкой, а не просто её угадать или подобрать.
Но в обоих сценариях фундаментальная проблема одна и та же: сервер Max не выполняет повторную авторизационную проверку при обращении по прямому URL и доверяет самому факту знания адреса. В результате приватность файла опирается на секретность ссылки, а не на проверку прав пользователя — именно это в международной практике и у профильных организаций вроде OWASP квалифицируется как ошибка контроля доступа (типичный IDOR, Insecure Direct Object Reference). Для мессенджера, который позиционируется как «защищённый нацсервис», такое поведение выглядит особенно уязвимо.
Оценка по CVSS для первого сценария
Чтобы уйти от эмоциональных оценок и оперировать формальными метриками, автор анализа применяет к ситуации стандарт CVSS 3.1, который используют для численной оценки уязвимостей. Для первого сценария — когда любой, кто знает прямой URL, может без авторизации открыть фото — получается следующий вектор: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Это означает сетевой вектор атаки, низкую сложность эксплуатации, отсутствие требований к привилегиям и участию пользователя, отсутствие влияния на целостность и доступность, но высокий ущерб конфиденциальности.
Числовой результат такого вектора — 7.5 балла по CVSS 3.1, что в принятых градациях относится к «высокому» уровню критичности. В российских реалиях подобные оценки соотносятся с методиками ФСТЭК, которые разбивают угрозы по уровням значимости для персональных данных и объектов критической информационной инфраструктуры. Иными словами, при сценарии «любой человек с прямым URL может без авторизации открыть фото» речь идёт не о мелком баге, а о серьёзной уязвимости, требующей первоочередного устранения.
Оценка по CVSS для сценария с утечкой ссылки
Во втором рассматриваемом сценарии предполагается, что URL изначально недоступен случайным лицам и становится известен злоумышленнику только после того, как владелец сам создал риск компрометации — переслал ссылку, сохранил её в небезопасном месте и так далее. В этом случае меняется всего один параметр вектора CVSS: появляется требование к внешнему действию пользователя, и метрика UI (User Interaction) из N (нет) превращается в R (требуется). Получаем вектор AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N с итоговой оценкой порядка 6.5 балла.
Формально эта оценка уже попадает в диапазон «среднего» уровня угрозы. Однако даже при таком допущении стандартные методики всё равно не позволяют трактовать поведение Max как норму или некритичную особенность. Законодательство и регуляторные практики исходят из того, что частные файлы и сообщения должны быть защищены по умолчанию, а любые механизмы открытого доступа по ссылке — чётко отделены, задокументированы и подкреплены осознанным согласием пользователя.
Почему длина ссылки не спасает от уязвимости
Отдельный аргумент в пользу «безопасности» схемы Max звучит так: часть URL уникальна и достаточно длинна (десятки символов с высокой энтропией), поэтому перебор адресов якобы невозможен на практике. В строгой математике это действительно серьёзно усложняет прямой брутфорс, но в мировой практике безопасности давно утвердился принцип: сложный или длинный идентификатор не может заменять проверку прав доступа. Даже OWASP прямо относит подобные конструкции к уязвимостям класса IDOR, если сервер выдаёт объект только по знанию его идентификатора.
Реальная жизнь ещё суровее: утечки ссылок происходят постоянно — через логи веб‑серверов и прокси, историю браузера, расширения, скриншоты, резервные копии, ошибочные пересылки и так далее. Для обычного пользователя разница между «ссылка очень длинная» и «файл реально защищён» огромна. В первом случае любая компрометация адреса превращает личное фото в почти публичный объект, во втором — сервер на каждом обращении сверяет права доступа и просто не отдаёт содержимое посторонним.
Позиция Securitylab и OWASP
Профильные специалисты подчёркивают, что корень проблемы не в математике, а в архитектуре: приватность не должна держаться на секретности URL. Организации вроде OWASP рассматривают такие сценарии как очевидное нарушение принципов безопасного проектирования, поскольку доступ к объекту (файлу, записи, документу) должен контролироваться по идентичности и правам пользователя, а не по знанию некоего «волшебного» идентификатора. Сложный токен может быть лишь вспомогательной мерой против перебора, но никак не основной защитой.
Комментируя кейс Max, эксперты из медиа и профильных ресурсов указывают, что для защищённого мессенджера корректная модель проста: при каждом открытии файла сервер валидирует сессию, проверяет принадлежность файла конкретному пользователю или чату и блокирует доступ посторонним, даже если им как‑то достался точный URL. Всё остальное больше похоже не на приватный мессенджер, а на файловый хостинг с тонкой обёрткой в виде интерфейса переписки — удобно, но небезопасно для чувствительных данных.
Ответ Max и юридический аспект хранения данных
Пресс‑служба Max оперативно отреагировала на первую волну публикаций, назвав сообщения о «сливе личных фото» фейком и заявив, что личные изображения недоступны никому, кроме владельца, а ссылки якобы нельзя подобрать или сгенерировать. По официальной версии, другие пользователи могут увидеть фото только если владелец добровольно поделится ими или URL, а все данные пользователей «надёжно защищены». На фоне практических примеров с открытыми ссылками и архивами из общедоступного интернета такие заявления выглядят скорее попыткой погасить репутационный пожар, чем техническим разбором ситуации.
Позднее всплыло важное уточнение: ссылки и сами файлы продолжают существовать и открываться по URL даже после того, как пользователь удалил картинку из чата. Представители Max объясняют это необходимостью соблюдения требований российского законодательства по хранению данных, которые обязывают оператора удерживать определённые категории информации в течение заданного срока. Однако регуляторные нормы не обязывают держать эти данные в режиме открытого чтения по прямой ссылке без авторизации — это уже чисто архитектурное решение разработчика.
Национальный мессенджер и ожидания защиты
Контекст значительно усиливает серьёзность инцидента: Max позиционируется как национальный мессенджер, в котором «в порядке вещей и безопасно» должны передаваться любые документы — от рабочих файлов и отчётности до сканов паспортов и медицинских справок. Пользователь вправе ожидать, что такие данные защищены не хуже банковских сервисов, а не лежат в сети за длинной, но всё же доступной ссылкой. В такой ситуации аргумент «перебор сложен» звучит особенно слабым: злоумышленнику достаточно один раз получить доступ к конкретному URL или схеме его формирования, чтобы использовать уязвимость по максимуму.
Даже если в рассматриваемых кейсах в сети всплыли преимущественно иконки каналов и публичные изображения, уже сам факт наличия пользовательских фотографий в этой массе показывает, что граница между «публичным» и «личным» размыта. При нынешней архитектуре ничто принципиально не мешает аналогичным образом всплыть медицинским документам, конфиденциальной корпоративной переписке или банковским данным — вопрос лишь времени, объёма и мотивации атакующих.
Практические выводы и рекомендации пользователям
С позиции методик ФСТЭК и формальной оценки по CVSS, описанная ситуация с прямыми URL в Max укладывается минимум в средний, а в худшем случае — в высокий уровень угрозы. Это не «особенность реализации», а полноценная уязвимость контроля доступа, связанная с тем, что сервер не проверяет права при обращении к файлу по ссылке. Сложность перебора и длина токена в URL не отменяют необходимости авторизационной проверки и не могут использоваться как оправдание сохранения текущего поведения.
Пока разработчики Max не внедрят полноценную проверку прав доступа к файлам и не изменят логику хранения и удаления медиа, пользователям разумно относиться к мессенджеру как к небезопасному каналу для любых чувствительных данных. Не стоит пересылать через Max фотографии документов, банковские карты, медицинские заключения, рабочие конфиденциальные файлы и иные материалы, утечка которых может причинить серьёзный ущерб. Для пересылки критичных данных лучше использовать каналы с проверенной реализацией end‑to‑end‑шифрования и строгим серверным контролем доступа, а также включать двухфакторную аутентификацию и минимизировать хранение таких файлов в облаке.
Что должен сделать разработчик мессенджера
Для исправления ситуации команде Max необходимо изменить архитектуру работы с медиафайлами. Во‑первых, доступ к изображениям и документам по URL должен быть завязан на проверку сессии и прав доступа: без действующей авторизации и принадлежности к соответствующему чату или каналу файл не должен отдаваться вообще. Во‑вторых, удаление медиа из переписки должно явно отражаться в политике хранения на сервере: даже если закон требует удерживать данные, оператор может хранить их в зашифрованном и недоступном по прямым ссылкам виде.
В долгосрочной перспективе национальные мессенджеры, претендующие на роль инфраструктурных сервисов, обязаны внедрять практики безопасного проектирования уже на этапе архитектуры. Это включает использование признанных стандартов оценки уязвимостей (CVSS), учёт требований регуляторов вроде ФСТЭК, регулярные внешние аудиты безопасности и прозрачное взаимодействие с экспертным сообществом. В противном случае любой «удобный костыль» в виде прямых URL может быстро превратиться в масштабный инцидент утечки персональных данных, восстановить доверие после которого будет крайне сложно.
