Практическая ситуация: страница восстановления пароля содержит токен в URL. Как проверить, не утекает ли он через заголовок Referer при переходе на внешний ресурс?
Нужно открыть страницу с тестовым токеном, инициировать переход на контролируемый внешний ресурс и проверить полученный заголовок Referer. Если в нём передаётся полный URL с токеном, приложение допускает утечку секрета.
Надёжная защита — не помещать чувствительный токен в URL либо запретить его передачу через Referrer-Policy, удалить токен из адреса после обработки и ограничить срок его действия и повторное использование.
Заголовок Referer появился как механизм передачи странице адреса источника перехода. Он помогал анализировать навигацию, строить статистику посещений и поддерживать отдельные сценарии контроля источника запроса.
Проблема возникла из-за того, что URL часто содержит не только маршрут, но и чувствительные параметры: токены восстановления, идентификаторы сессий или внутренние поисковые запросы. При переходе на сторонний ресурс такой URL мог быть передан автоматически, поэтому браузеры и веб-серверы получили настройки управления политикой отправки источника.
Если токен восстановления находится в строке запроса, его могут получить сторонние системы аналитики, рекламные счётчики, внешние изображения, ссылки или страницы, на которые пользователь перейдёт с текущего экрана. Утечка особенно опасна, если токен позволяет установить новый пароль без дополнительной аутентификации.
Проверка только адресной строки недостаточна. Нужно учитывать фактические исходящие запросы, переходы через промежуточные страницы, редиректы и сторонние ресурсы, загружаемые автоматически.
Тестировщик создаёт действительный тестовый токен и открывает страницу восстановления. Затем он выполняет переход на контролируемый домен, например через ссылку, внешний ресурс или тестовую страницу, которая фиксирует входящие HTTP-заголовки.
В журнале контролируемого ресурса проверяется значение Referer. Небезопасный результат — наличие полного адреса страницы восстановления вместе с токеном. Безопаснее, когда заголовок отсутствует или содержит только источник без пути и параметров.
Следует повторить проверку для разных направлений перехода:
Предпочтительно передавать секрет через тело защищённого запроса, а не через URL. Если токен уже использован из URL, приложение может немедленно заменить адрес на безопасный через редирект без токена; это уменьшает дальнейшее распространение секрета, но не устраняет риск утечки во время первого открытия страницы.
Referrer-Policy снижает вероятность передачи URL, но не заменяет правильный дизайн. Политика no-referrer полностью запрещает отправку источника, а политика, ограничивающая источник только схемой, доменом и портом, скрывает путь и параметры при междоменном переходе. Нельзя полагаться только на поведение конкретного браузера: важны серверная конфигурация, встроенные клиенты и промежуточные компоненты.
Токен должен быть одноразовым, короткоживущим и связанным с конкретным сценарием восстановления. Эти меры ограничивают последствия утечки, но не делают саму утечку приемлемой.
В приложении ссылка восстановления имела вид с токеном в параметре URL. На странице работал внешний счётчик посещений, и тестовый внешний сервер получил полный адрес страницы вместе с токеном через Referer.
Рассматривались три варианта. Полный запрет внешних ресурсов уменьшал поверхность атаки, но ломал аналитику и часть пользовательского интерфейса. Только установка ограничительной политики источника снижала риск, однако оставляла секрет в истории браузера, журналах прокси и системах аналитики. Перенос токена в тело запроса устранял его передачу через URL, но требовал изменения сценария восстановления.
Выбрали комбинацию: токен принимался в начальном запросе, после чего приложение выполняло редирект на адрес без токена; сам токен сделали одноразовым и короткоживущим, а для страницы установили запрет передачи источника. В результате внешние запросы больше не содержали токен, а даже потенциально перехваченный старый токен не позволял повторно изменить пароль.
Нет. Политика управляет передачей заголовка Referer, но токен всё ещё может попасть в историю браузера, журналы веб-сервера, прокси, системы мониторинга, адресные закладки или скриншоты. Кроме того, риск зависит от корректности применения политики и поведения поддерживаемых клиентов. Поэтому чувствительные значения не следует помещать в URL даже при наличии защитного заголовка.
Редирект после обработки токена существенно уменьшает последующее распространение секрета, но не отменяет риск на исходном запросе. До редиректа страница могла загрузить внешний ресурс или выполнить переход, а исходный URL уже мог попасть в серверный журнал. Поэтому редирект должен сочетаться с отсутствием стороннего содержимого на начальной странице, одноразовостью токена и безопасной политикой источника.
HTTPS защищает передачу между клиентом и конкретным сервером, но не препятствует самому браузеру отправить URL стороннему ресурсу в заголовке Referer. Внешний сервер получит значение уже через разрешённый браузером HTTPS-запрос. Шифрование канала не заменяет минимизацию секретов в URL, ограничение их срока действия и контроль политики передачи источника.