Короткая ссылка с защитой паролем - это короткий URL, который запрашивает пароль перед тем, как перенаправить кого-либо дальше. Вы открываете ссылку, попадаете на небольшую промежуточную страницу вместо адреса назначения, вводите пароль - и только тогда выполняется редирект. Введёте пароль неверно - останетесь на странице запроса. Адрес назначения никогда не раскрывается, пока проверка не пройдена.
Вот и весь принцип, и стоит быть точным в нём, потому что название преувеличивает защиту. Паролевый шлюз - это барьер доступа перед ссылкой. Это не шифрование страницы, стоящей за ссылкой. Это разные гарантии, и путаница между ними приводит к неприятным сюрпризам. В этом посте рассматривается, для чего шлюз хорош, какие случаи использования ему действительно подходят, как проверка работает на уровне редиректа, где безопасность заканчивается и что с ним объединить, чтобы система была устойчивой.
Для чего нужна короткая ссылка с защитой паролем#
Полезные случаи использования имеют одну форму: вы передаёте ссылку по каналу, который не полностью контролируете, и хотите, чтобы для входа требовалось что-то помимо URL.
Конфиденциальный документ - очевидный пример. Вы отправляете черновик договора, финансовую модель или внутреннюю презентацию кому-то за пределами вашей компании. Письма пересылают. PDF-файлы перенаправляют. Короткая ссылка, которую может открыть любой с URL, настолько конфиденциальна, насколько аккуратен самый небрежный человек, когда-либо державший её. Поставьте пароль - и случайная пересылка больше не означает автоматического доступа.
Материалы для клиентов - тот же паттерн с дедлайном. Агентство передаёт набор ресурсов, смонтированное видео, отчёт по кампании. Клиент должен иметь доступ, а вот вся адресная книга клиента - нет. Ссылка с шлюзом хранит материалы за общим секретом, который вы задаёте при создании ссылки.
Список дополняют частные кампании и закрытый контент. Предзапусковая целевая страница, которую хочет предварительно просмотреть небольшая группа. Предложение раннего доступа для листа ожидания. Ресурс только для членов сообщества, где аудитория уже имеет пароль из другого источника. В каждом из этих случаев ссылка распространяется по электронной почте или в чате, и пароль - это то, что отделяет «мне это дали» от «я на это наткнулся случайно».
Что не подходит: что-либо по-настоящему секретное, что-либо регулируемое, что-либо, утечка чего является инцидентом, требующим уведомления. Для таких случаев общий пароль ссылки слишком груб. Вам нужна персональная аутентификация на самом адресе назначения - это другой контроль, к которому я ещё вернусь.
Как работает паролевый шлюз на уровне редиректа#
Вот механическая часть, потому что порядок операций определяет значимость шлюза.
Обычная короткая ссылка - это редирект. Пограничный сервер ищет слаг, находит адрес назначения и отправляет 302 браузеру посетителя. Быстро, без состояния, без вопросов. Короткая ссылка с паролем вставляет один шаг перед редиректом: сервер видит, что для ссылки установлен пароль, и вместо пересылки возвращает запрос. Посетитель получает промежуточную страницу с вводом пароля. Он его вводит. Введённое значение сверяется с сохранённым хэшем. Если совпадает - редирект выполняется. Если нет - остаётся на странице запроса, и URL назначения никогда не отправляется браузеру.
Два важных момента, определяющих ценность этого механизма.
Первый: пароль хэшируется, никогда не хранится в открытом виде. Сохранённый секрет ссылки должен быть необратимым хэшем, чтобы чтение базы данных не выдавало злоумышленнику все пароли ссылок системы. Argon2id - текущая рекомендация для хэширования паролей, и именно его Elido использует для паролей ссылок, при этом проверка выполняется в процессе с использованием сравнения с постоянным временем, чтобы сама проверка не утекала информацию через тайминг. API для ссылки никогда не возвращает хэш; он возвращает булево значение, указывающее, установлен ли пароль. Получатель, обращающийся к защищённой ссылке, получает 401 с флагом password_required и токеном запроса и должен отправить верный пароль в следующем запросе, прежде чем выполнится редирект. Механика этого хранения изложена в контрольном списке безопасности сокращателя URL, в разделе о защите паролем отдельных ссылок.
Второй: проверка происходит до раскрытия адреса назначения. Это звучит очевидно, но удивительное количество «приватных» схем ссылок раскрывают адрес назначения в клиентском коде или в цепочке редиректов, которую определённый посетитель может прочитать напрямую. Смысл выполнения проверки на редиректе, на стороне сервера, в том, что URL назначения остаётся на сервере, пока пароль не верен. Если вы когда-либо видели шлюз, реализованный как JavaScript, который получает реальный URL и затем перенаправляет - вы видели шлюз, через который любой с инструментами разработчика браузера может пройти напрямую. Серверная оценка - ключевое отличие, та же логика, из-за которой умные ссылки маршрутизируются на пограничном уровне, а не в JS-прослойке на целевой странице.
Ограничения безопасности, сказанные прямо#
Это раздел, который люди пропускают, а потом жалеют, поэтому он стоит в середине, где его сложно пропустить.
Паролевый шлюз защищает короткую ссылку. Он не защищает адрес назначения. Если адрес назначения - публичный URL, который кто угодно может открыть, набрав его напрямую, то пароль останавливает только тех, у кого есть короткая ссылка, но не тех, кто может угадать или случайно наткнуться на базовую страницу. Шлюз повышает планку для типичного случая общего доступа, когда у людей есть только короткий URL. Для уже раскрытого адреса назначения он не делает ничего.
Значит, правило простое: адрес назначения тоже должен быть защищён. Документ за короткой ссылкой с паролем должен также находиться в месте, которое проверяет, кто вы, а не просто где-то с длинным, угадать который сложно, путём. OWASP Authentication Cheat Sheet и сопутствующее руководство по контролю доступа - справочник здесь: аутентификация подтверждает, кто вы есть, контроль доступа определяет, что вы можете достичь, а общий пароль ссылки - слабая форма первого, которая ничего не говорит о втором. Используйте его как удобный слой, а не как щит между злоумышленником и регулируемыми данными.
Ещё несколько честных ограничений.
Общий пароль является общим. Все, у кого он есть, - одна идентификация для шлюза. Нет пословного журнала того, кто открыл ссылку, нет способа отозвать доступ одного человека без смены пароля для всех. Если вам нужно знать, что именно Дана открыла материалы, общий пароль ссылки вам этого не скажет.
Ссылка должна обслуживаться по HTTPS - всегда. Пароль, отправленный по обычному HTTP, передаётся в открытом виде всем на сетевом пути. Шифрование транспорта - это минимум, а не функция; обзор HTTPS на MDN объясняет почему. Elido обслуживает редиректы по HTTPS по умолчанию, включая кастомные домены, но принцип действует везде, где вы ставите шлюз.
И пароль не заменяет срок действия. Ссылка, которая живёт вечно, - это риск независимо от наличия пароля, потому что секрет медленно утекает по мере того, как его вставляют всё в большее количество мест. Сочетайте шлюз с ограниченным сроком жизни.
С чем сочетать#
Паролевый шлюз - один из механизмов защиты. Он работает лучше всего в сочетании с другими, которые покрывают то, что он не может.
Срок действия и лимиты кликов ограничивают ссылку во времени и использовании. Задайте expires_at, чтобы материалы для клиента стали недоступны после завершения сотрудничества, и лимит кликов, чтобы одноразовая ссылка на скачивание деактивировалась после однократного открытия. Оба механизма проверяются на редиректе до записи какого-либо события клика, что означает: попытка ввода неверного пароля против уже истёкшей ссылки вообще не достигает шлюза. Компромиссы в отношении срока жизни рассмотрены в статье истечение срока ссылки и самоуничтожающиеся ссылки.
IP-ограничения или геоограничения сужают круг тех, кто вообще может попытаться пройти через шлюз. Если материалы для клиента всегда открываются из одного офиса, ограничение ссылки этим диапазоном означает, что утечка пароля вместе с утечкой ссылки всё равно не сработает из любого другого места. Региональные ограничения рассмотрены в статье геотаргетинг коротких ссылок, и они сочетаются с паролем, а не заменяют его.
Для команд правильный ответ - как правило, вообще не общий пароль, а SSO. Когда люди, которые должны иметь доступ к ссылке, являются сотрудниками вашего поставщика идентификации, защитите адрес назначения с помощью SCIM и SSO, чтобы доступ следовал за директорией: человек уходит из компании - доступ исчезает, без необходимости смены пароля. Общий пароль ссылки подходит для ad-hoc внешнего общего доступа; управление доступом через директорию - для всего, где нужен отзыв доступа по отдельным пользователям. Руководство по настройке SCIM и SSO описывает подключение, а страница корпоративных решений охватывает, где это применяется.
Общий принцип - многоуровневая защита. Ни один из механизмов здесь не достаточно сильный сам по себе. Пароль останавливает случайный доступ, срок действия ограничивает окно, HTTPS защищает канал передачи, контроль доступа к адресу назначения защищает контент, а SSO решает командный случай. Комбинируйте те, которые нужны вашей ситуации.
Практическое руководство#
Если вы хотите защитить ссылку шлюзом, порядок действий одинаков независимо от инструмента.
Задайте пароль при создании или редактировании ссылки. В настройках ссылки должна быть возможность прикрепить пароль; после его установки ссылка перестаёт быть обычным редиректом и начинает возвращать запрос. Выберите пароль, который не угадывается тривиально и не совпадает с паролем из другого места, потому что общий секрет, который также открывает вашу электронную почту, - плохой общий секрет.
Отправьте ссылку и пароль по разным каналам. Это привычка с наибольшей ценностью. Отправьте короткую ссылку в письме или документе, а пароль - в сообщении в чате, отдельном письме или по телефону. Если оба путешествуют в одном сообщении, одно перехваченное сообщение отдаёт всё, и шлюз не принесёт никакой пользы. Разделение означает, что злоумышленнику нужны два канала, а не один.
Одновременно задайте срок действия. Заранее решите, как долго должна жить ссылка и должна ли она деактивироваться после известного числа открытий, и задайте это при создании, а не обещайте себе убрать потом. Не уберёте.
Убедитесь, что адрес назначения имеет собственный контроль доступа, если контент конфиденциален. Шлюз делает своё дело для случая общего доступа. Если базовый документ также должен быть защищён от кого-то, угадавшего URL, - эта защита должна быть на адресе назначения, а не на короткой ссылке. Для более полного рассмотрения того, как эти части вписываются в модель угроз, статья безопасны ли сокращатели URL рассматривает более широкую картину, а страница доверия описывает позицию Elido.
Вот честная версия коротких ссылок с защитой паролем. Это удобный, малозатратный способ предотвратить открытие общего URL любым, кто его случайно получает. Это не хранилище. Используемые как один уровень в стеке, вместе со сроком действия и должным образом защищённым адресом назначения, они выполняют именно ту задачу, которую должны. Используемые как единственное, что стоит между злоумышленником и чем-то важным, - подведут. Поставьте шлюз, разделите каналы, ограничьте срок жизни и защитите адрес назначения - и у вас будет процесс общего доступа, который выдержит.
Если хотите узнать, какие механизмы защиты есть на каком тарифе - страница тарифов их перечисляет, а функция кастомных доменов описывает обслуживание ссылок с шлюзом на собственном брендированном домене по HTTPS. Настройка этого описана в статье как настроить брендированные короткие ссылки.