Безопасность NeyLivo

Подход

Три правила, которых проект держится.

• Нет утверждения без кода за ним. Всё на этой странице соответствует чему-то в открытом исходнике. Если защиты нет, о ней не пишут так, будто она есть.
• Никакого тихого отката. Если зашифровать не удалось, сообщение не отправляется вовсе и человек видит причину. Защита, которая молча выключается сама, хуже её отсутствия: в неё продолжают верить.
• Пределы названы. Честно названное ограничение полезнее уверенного лозунга. Раздел о слабых местах ниже — не приписка в конце, а смысл всей страницы.

Защита сообщений

Личную переписку двух людей можно шифровать от устройства до устройства. Когда шифрование включено, на сервере лежит шифротекст, ключа от которого у сервера нет.

Сквозным шифрованием не защищены: групповые беседы и каналы серверов. Эти сообщения хранятся так, что сервер может их прочитать, и защищены правилами доступа к базе — та же модель, что у большинства групповых мессенджеров. Если нужна переписка, которую сервер прочитать не может, — это личная переписка один на один с включённым шифрованием.

Если у собеседника нет опубликованного ключа — например, он ни разу не заходил с версией, которая умеет шифровать, — сообщение не отправляется, и приложение говорит об этом. Тихо перейти на открытый текст оно не может.

Защита канала связи

Весь обмен приложения с сервером идёт по HTTPS/TLS, включая соединение реального времени (защищённый WebSocket) и загрузку файлов. Плагину доступны только https: и wss:, обычный HTTP отклоняется.

Приложение для Windows скачивается по HTTPS и обновляется по HTTPS, сверяя контрольную сумму SHA-512, опубликованную вместе с выпуском. Эта сумма подтверждает, что файл дошёл целым; подписью кода она не является, и установщик сертификатом не подписан.

Защита учётной записи

Учётными записями занимается Supabase Auth. Сессия — это JWT с токеном обновления, который хранится локально на устройстве (а на Android дополнительно в нативном хранилище, чтобы обновление приложения не выкидывало из аккаунта).

• Доверенные устройства. Вход с незнакомого устройства помечает его как новое, и оно остаётся ограниченным, пока его не подтвердят. Остальные устройства получают оповещение.
• Код восстановления. На сервере хранится только его отпечаток SHA-256, никогда сам код: утечка базы не раздаёт главные ключи от учётных записей.
• Вход по QR. На новом устройстве можно войти, отсканировав код тем, где вход уже выполнен.
• Юзернейм или почта. Вход по юзернейму идёт через отдельную функцию, которая отвечает одинаково на «такого нет» и «пароль неверный», — по ней нельзя узнать, кто существует.
• Удаление учётной записи. Учётную запись и её данные можно удалить прямо из приложения.

Двухфакторной проверки с приложением-аутентификатором пока нет. Доверенные устройства и код восстановления — частичная замена, а не полная.

Хранение паролей

NeyLivo не хранит пароли. Ими занимается Supabase Auth, который держит их как хеши bcrypt; собственного кода хранения паролей в проекте нет.

Минимальная длина пароля — шесть символов, это значение платформы по умолчанию. Это мало, и поднять порог — в списке того, что надо исправить.

Вложения

Для личной переписки есть переключатель, который это чинит: шифровать вложения. С ним каждый файл шифруется прямо в браузере своим ключом AES-256-GCM ещё до отправки, лежит под нейтральным именем и без типа, а ключ едет внутри зашифрованного сообщения — то есть достать его можно, только расшифровав переписку. Как и остальные переключатели шифрования, по умолчанию он выключен.

Пока хранилище не закрыто, считайте всё отправленное без шифрования вложений технически общедоступным. Это ограничение перечислено ниже и в собственном аудите проекта.

Голос и видео

Звонки идут через LiveKit. Право позвонить решает сервер, а не приложение: блокировка и настройка «кто может мне звонить» проверяются в той службе, которая выдаёт пропуск в звонок, поэтому обойти проверку изменённым клиентом нельзя.

Звонок двух людей можно зашифровать сквозным шифрованием — отдельной настройкой. Ключ вырабатывается в браузере и уезжает собеседнику внутри зашифрованного сообщения, так что сервер звонков его не видит.

Без шифрования звонка поток расшифровывается на медиасервере — как в любом обычном групповом звонке. Голосовые каналы серверов сквозным шифрованием не защищены.

Изоляция плагинов

Код плагина работает не в приложении. Он работает в Web Worker, которому браузер не даёт ни DOM, ни куки, ни доступа к странице, — поэтому плагин не может прочитать вашу сессию, не может нарисовать поддельное окно входа и не может влезть в интерфейс.

Плагинам, которым нужна целая страница (игры, визуализаторы, 3D-сцены), достаётся <iframe sandbox="allow-scripts"> без allow-same-origin. Это даёт странице уникальное чужое происхождение: у неё есть свой DOM, работают WebGL, WebAssembly и звук, но она — другое происхождение, и ни документа NeyLivo, ни его хранилища ей не достаётся.

Это границы браузера, а не наши проверки, которые хитрый плагин уговорит. Всё, что плагину доступно, проходит через один диспетчер, и каждый вызов сверяется с объявленными разрешениями. На попытки обхода есть отдельный набор проверок, который нарочно штурмует эти границы.

Разрешения плагинов

Перед установкой видно имя плагина, автора, версию и точный список того, что он просит, человеческими словами — например «Отправлять сообщения от твоего имени» или «Обращаться в интернет (только к указанным сайтам)». Всего таких разрешений 23.

Две вещи, которые надо знать. Плагин, объявивший * — или не объявивший ничего, — просит все разрешения сразу, и на экране установки это показано красным. И количественных пределов нет: установленный плагин может отправлять сообщения, ходить в сеть и работать в фоне сколько угодно. Приложение говорит об этом до установки, потому что настоящая защита здесь — ваше решение, а не квота.

Плагин можно в любой момент выключить или удалить.

Доступ плагинов в сеть

В интернет плагин выходит, только если у него есть разрешение на сеть, и только на домены, объявленные им в шапке. Правила проверяются в одном месте для всех способов выйти — обычный запрос, поток и постоянное соединение, — чтобы второй путь не разошёлся с первым:

• Только https: и wss:, обычный HTTP отклоняется
• Только объявленные домены — или любые, если плагин попросил об этом открыто и человек согласился
• Никогда к самому NeyLivo и его серверу: плагин не может обратить вашу сессию против приложения
• Заголовки только из белого списка; Cookie не разрешён никогда

Метаданные

Шифрование скрывает, что вы написали. Оно не скрывает, что вы писали. Даже со всеми включёнными настройками серверу известно:

• Какие учётные записи существуют, их имена, аватары и поля профиля
• Кто с кем переписывается и когда отправлялись сообщения
• В каких серверах и каналах вы состоите
• Что состоялся звонок, между кем и сколько он длился
• Примерное время подключений и IP-адрес, с которого устройство подключается, — как у любой сетевой службы

Длина сообщения скрыта дополнением, а у зашифрованного вложения нет ни имени файла, ни типа. Остальное из списка выше — метаданные, которые NeyLivo сейчас не сокращает.

Инфраструктура

NeyLivo не держит собственную инфраструктуру. Он работает на:

• Supabase. База данных, учётные записи, хранилище файлов и соединение реального времени. Доступ определяют правила уровня строк, которые проверяются на настоящем Postgres при каждом изменении.
• LiveKit. Голос, видео и демонстрация экрана. Занимается только медиапотоком.
• GitHub. Исходный код, автоматическая сборка и файлы выпусков, на которые ведёт этот сайт.

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

Известные слабые места

Список слабых мест, который проект ведёт сам, в том порядке, в каком собирается их закрывать:

1. Вложения в публичном хранилище. Файлы, отправленные без шифрования вложений, скачает любой, у кого есть ссылка. Исправление — закрыть хранилище и перейти на подписанные ссылки, не сломав те ссылки, что уже лежат внутри старых сообщений, — запланировано и делается по шагам.
2. Шифрование выключено по умолчанию. Приватность, которая работает только у того, кто нашёл её в настройках, — это приватность, которой большинство не получает.
3. Групповые беседы и каналы не защищены сквозным шифрованием. Групповое сквозное шифрование — отдельная и большая задача, и придумывать её на ходу никто не будет.
4. Шифрование звонков не проверено в жизни. В проверках оно работает; настоящим звонком не подтверждено.
5. Нет Content-Security-Policy. Известного пути для внедрения кода сегодня нет — сообщения рисуются узлами React, и вставки сырого HTML в приложении нет нигде, — но CSP это второй рубеж, который ловит завтрашнюю ошибку.
6. Картинки эмодзи грузятся с чужого CDN. Значит, посторонний видит ваш IP просто потому, что в интерфейсе есть эмодзи. Положить их в сборку несложно, и это запланировано.
7. Минимальная длина пароля — шесть символов. Мало.
8. Внешнего аудита не было. Никто со стороны всё это не проверял.

Полный технический разбор тех же находок, со ссылками на файлы, опубликован в репозитории как SECURITY_ARCHITECTURE_AUDIT.md. Открыть аудит →

Как сообщить об уязвимости

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

• Воспользуйтесь приватным сообщением об уязвимости в репозитории на GitHub или заведите короткое обращение с просьбой о личном канале — без подробностей.
• Опишите, что вы сделали, что произошло и почему считаете это проблемой. Короткое воспроизведение ценнее длинного описания.
• Пожалуйста, не публикуйте рабочие эксплойты, чужие данные и разбор до того, как появилось исправление.

Вознаграждения за уязвимости нет. Платить проекту нечем, а пообещать то, чего он не выполнит, было бы хуже, чем сказать это прямо.

Правила сообщения об уязвимостях в репозитории →  ·  Страница приватности →