Вернуться в блог
БезопасностьТехнологии

Одноразовые ссылки 2026: насколько безопасны? 4 реализации

Опубликовано8 min read
Поделиться

«Одноразовая» не равно «безопасная» — и вот почему

Функция «самоуничтожающихся ссылок» (burn-after-read) за последние годы стала мейнстримом. Пароли, конфиденциальные фото, временные документы — всё отправляют через «сгорающие» ссылки, думая, что это синоним безопасности. Честно говоря, это не так.

Разные сервисы реализуют burn-after-read принципиально по-разному. Некоторые физически не способны гарантировать уничтожение данных. Разберём три базовые схемы с позиции криптографии и системной архитектуры — и поймём, где на самом деле защита, а где маркетинг.

Три модели реализации

Модель 1. Серверное удаление (Token-Based)

Самая простая и самая распространённая:

  1. Пользователь загружает контент, сервер хранит оригинал и генерирует уникальный токен (UUID или случайная строка)
  2. Сервер возвращает ссылку с токеном (например, https://example.com/view/abc123)
  3. Первый посетитель открывает ссылку, сервер отдаёт данные и помечает токен как использованный
  4. Последующие запросы получают «ссылка недействительна»

Разбор безопасности:

Принципиальная проблема — сервер держит plaintext. До момента «уничтожения» доступ имеют:

  • Администратор сервера
  • Администратор БД
  • Любой атакующий, получивший root
  • Система бэкапов (если удалённые данные остались в бэкапе — они живы)
  • Суд, прокуратура, Роскомнадзор по запросу

Проще говоря: даже если сервер честно «удалил» файл после чтения, в современных СХД «удаление» — это лишь пометка на перезапись. До физического оверрайта данные восстанавливаются. TRIM у SSD и магнитные остатки на HDD — задокументированные каналы рекавери.

Модель 2. Клиентское шифрование (Zero-Knowledge)

Максимальный уровень безопасности. Представители — PrivNote, бывший Firefox Send:

  1. Пользователь вводит контент в браузере
  2. Браузер генерирует случайный AES-256 ключ
  3. На стороне клиента контент шифруется этим ключом
  4. На сервер уходит только ciphertext
  5. Сервер хранит шифротекст, ключа не видит
  6. Ключ прикрепляется к URL как fragment (после #)

Пример: https://example.com/view/abc123#encryption-key-here

Ключевая криптографическая деталь: fragment (всё после #) не отправляется на сервер. Сервер видит только ciphertext и никогда не знает ключа — расшифровать не может. Это и есть zero-knowledge архитектура.

Получатель открывает ссылку:

  1. Браузер получает шифротекст с сервера
  2. Извлекает ключ из fragment
  3. Расшифровывает локально
  4. Сервер удаляет ciphertext

Разбор безопасности:

Даже если сервер взломан, атакующий получит только нешифруемый ciphertext. Но остаются риски:

  • Расширения браузера: злоумышленное расширение может прочитать URL целиком, включая fragment
  • История браузера: полный URL с ключом остаётся в history
  • Referer-утечка: если на странице есть внешние ресурсы, fragment может протечь через Referer (современные браузеры это во многом починили)
  • JS-supply-chain-атака: если файл со скриптом шифрования подменён, ключ уйдёт на сервер атакующего

Модель 3. Гибрид

Сочетание клиентского шифрования и серверного контроля:

  1. Клиентское шифрование (как в Модели 2)
  2. Серверные ограничения (одноразовый токен + пароль + TTL)
  3. Многофакторка (например, пароль для получения ciphertext)
  4. После доступа — удаление, но с логом событий (не содержимого)

На практике — лучший баланс между защищённостью и удобством.

Чего burn-after-read в принципе не защищает

Независимо от модели, следующие векторы остаются вне зоны покрытия.

Скриншоты и запись экрана

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

CDN и прокси-кеши

Если «одноразовый» контент идёт через CDN, edge-ноды могут держать копию в кеше. Сервер-источник удалил — кеш живёт до истечения TTL. Часто забывают.

Правильное решение: Cache-Control: no-store, no-cache, must-revalidate и CDN-Cache-Control: no-store, чтобы CDN не кешировал такой контент.

Кеш браузера

Браузер может положить расшифрованный контент в локальный кеш. Картинки особенно уязвимы — image cache часто работает отдельно от политики страницы.

Сетевой мониторинг (MitM)

При чистой Token-модели без HTTPS любой промежуточный узел (провайдер, корпоративный firewall, фальшивый Wi-Fi) видит plaintext.

Даже с HTTPS в корпоративной сети может стоять SSL Inspection — устройство расшифровывает трафик и логирует. Клиентское шифрование (Модель 2) это нейтрализует: даже при расшифрованном TLS атакующий увидит только ciphertext.

Серверные логи

Даже если сам контент корректно удалён, access-логи хранят URL, IP, timestamps, User-Agent. В Token-модели эти логи позволяют ретроспективно коррелировать «кто когда откуда какой линк открыл».

Сравнение главных сервисов

По открытой документации и исходникам, на март 2026:

Сервис Шифрование Open source Где ключ Может ли сервер читать plaintext Пароль Ограничения
PrivNote Клиентский AES Нет URL fragment Нет (zero-knowledge) Нет Только текст
1ty.me Серверное Нет На сервере Да Опционально Только текст
Snappass (Pinterest) Серверный AES Да В URL path Да (ключ через сервер) Опционально Только текст
hat.sh Клиентский XChaCha20 Да URL fragment Нет (zero-knowledge) Нет Файлы
OnionShare Клиент + Tor Да Локально Нет Опционально Файлы
Yopass Клиентский OpenPGP Да URL fragment Нет (zero-knowledge) Нет Текст + файлы

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

Как правильно пользоваться одноразовыми ссылками

Подходящие сценарии

  • Одноразовые пароли, временные токены доступа
  • Конфиденциальная, но краткосрочно актуальная информация
  • Переписка, которую не стоит оставлять в истории мессенджера

Неподходящие сценарии

  • Высокоценная коммерческая тайна (нужен E2E-мессенджер — Signal, Matrix с E2E)
  • Ситуации, где нужна юридическая неоспоримость (удалённые ссылки не докажешь в суде)
  • Государственная тайна (только офлайновая передача)

Строгие рекомендации

  1. Выбирайте сервисы с клиентским шифрованием — сервер не должен читать контент
  2. Выбирайте open source — проверяемость важнее маркетинга
  3. Комбинируйте с паролем — перехват линка без пароля бесполезен
  4. Ссылку и пароль — по разным каналам — линк по email, пароль в Telegram
  5. В корпоративной сети — не отправляйте крайне чувствительные данные — SSL Inspection всё видит

Защита паролем на lpic.cc

В контексте шаринга изображений lpic.cc предлагает защиту паролем: при загрузке задаёте пароль, посмотреть картинку сможет только тот, кто его введёт.

По правде сказать, нужно разделять ожидания: защита паролем у lpic.cc — это серверное управление доступом (ближе к Модели 1), а не клиентское zero-knowledge. Значит:

  • Сервер держит оригинальный файл
  • Пароль — это контроль доступа, не end-to-end шифрование
  • Подходит для бытовой приватности: «не хочу, чтобы ссылку открыл случайный человек»
  • Не подходит для ситуаций, где нужен криптографический уровень

Если нужна военная секретность — берите специализированные E2E-инструменты (Signal для сообщений, OnionShare для файлов).

Российская специфика: СОРМ, 152-ФЗ и «пакет Яровой»

Стоит учитывать: для сервисов, работающих на российских серверах, существует требование СОРМ — операторы связи и «организаторы распространения информации» обязаны предоставлять ФСБ доступ к трафику и метаданным. «Пакет Яровой» требует от них же хранить содержимое переписки и медиафайлов до 6 месяцев.

Что это значит на практике:

  • Одноразовые ссылки на российских сервисах (с регистрацией в реестре Роскомнадзора) — не гарантируют anonymity от государства
  • Zero-knowledge сервисы на зарубежных серверах обходят СОРМ, но могут попадать под санкции/блокировки
  • Для бытовых задач — неважно. Для журналистики, активизма — критично

Плюс ФЗ-152 требует, чтобы персональные данные россиян хранились на серверах в РФ. Для одноразовых ссылок это редко становится проблемой (они краткосрочны), но формально — помните.

Частые вопросы

Q1. Если ссылку открыли — данные точно невосстановимы?

Зависит от модели. В Token-модели данные могут жить в бэкапах, CDN-кеше или неперезаписанных секторах диска. В клиент-шифровании — если ключ уничтожен (URL нигде не сохранён), ciphertext криптографически невосстановим. Но то, что уже отрисовалось на экране получателя, никуда не денешь.

Q2. Помогает ли приватный режим браузера?

Отчасти. Приватный режим не сохраняет историю, cookies и локальный кеш — значит, URL с ключом не запишется. Но от сетевого мониторинга (провайдер, корпоративный прокси) и от скриншотов приватность не защищает.

Q3. А «автоматическое уничтожение через 30 секунд» — работает?

На уровне безопасности — почти ничего не даёт. Это JS-таймер, который чистит DOM. Любой открывает DevTools, ставит breakpoint — таймер останавливается. Ценность у этого скорее психологическая: сигнализирует получателю «это важно».

Q4. Можно ли ими предотвратить пересылку?

Нет. Получатель пересылает ссылку до открытия — и другой человек откроет раньше адресата. Пароль снижает риск (нужно знать и ссылку, и пароль одновременно), но после открытия получатель всё равно может заскринить и переслать скриншот.

Q5. Безопасно ли отправлять пароли через одноразовые ссылки на работе?

Лучше, чем plaintext в чате, но в корпоративе есть нюанс. Многие компании включают SSL Inspection — IT видит содержимое HTTPS. С клиентским шифрованием это нейтрализуется: даже при расшифрованном TLS IT увидит только ciphertext. В корпоративе приоритет — Yopass, hat.sh (open source + zero-knowledge).

Источники

#одноразовая ссылка#burn after read#криптография#защита данных#конфиденциальность#zero-knowledge
K

Автор

Kevin Wu

Консультант по безопасности

Конфиденциальность и безопасность данных. Ведь каждая фотография рассказывает историю, которую не все должны читать.