Статья Тихая угроза: уязвимости Open Redirect в клиентских приложениях с OAuth

[Admin]

Тихая угроза: уязвимости Open Redirect в клиентских приложениях с OAuth​

Если сервер авторизации OAuth (AS) поддерживает самостоятельную регистрацию клиентских приложений, а также скрытую аутентификацию, то, скорее всего, его можно использовать в качестве открытого редиректора

Клиентские приложения OAuth з самостоятельной регистрацией​

Широкое распространение OAuth объясняется в значительной мере благодаря тому, что дает разработчикам возможность регистрировать собственные клиентские приложения на различных платформах. Часто это делается с помощью процесса самостоятельной регистрации, который и обеспечивает гибкость и адаптивность OAuth.

Такие платформы, как Facebook, Google и Microsoft, позволяют разработчикам регистрировать собственные клиентские приложения OAuth. Этот процесс обычно включает предоставление разработчиком сведений о своем приложении, таких как его название, сайт и предполагаемое использование интеграции OAuth.

Тихая авторизация

Тихая авторизация в контексте OAuth/OIDC — это механизм, который упрощает пользовательский опыт за счет сокращения количества повторных входов в систему и запросов согласия при каждом запуске OAuth-потока.

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

Использование самостоятельной регистрации и тихой авторизации клиентских приложений для уязвимостей типа Open Redirect​

Комбинация саморегистрации клиентских приложений и тихой авторизации в реализациях OAuth может в некоторых случаях использоваться для создания открытых перенаправлений (open redirects).

Как все устроено​

1. Регистрация клиентского приложения: Злоумышленник регистрирует свое клиентское приложение на платформе, которая предоставляет портал самообслуживания для разработчиков (например, developer.example.com) с поддержкой OAuth. Обычно этот процесс включает отправку основной информации о приложении и получение учетных данных OAuth (идентификатор клиента и секретное слово).
2. Создание открытого перенаправления:

• Под видом разработчика клиентского приложения наш злоумышленник регистрирует локацию redirect_uri с нужным ему URL-адресом назначения. Этот параметр определяет, куда пользователь будет перенаправлен после авторизации в стандартном процессе OAuth.
• Зарегистрировав вредоносное приложение и указав желаемый адрес в качестве допустимого redirect URI, злоумышленник использует тихую авторизацию в своих целях, устанавливая значение параметра prompt на конечной точке авторизации в none: prompt=none
• 
• Исполнение и последствия: В реализации, поддерживающей тихую авторизацию, такое открытие конечной точки авторизации для клиентского приложения приведет к ошибке — либо из-за отсутствия активной сессии, либо если пользователь авторизован, но не дал разрешения этому приложению. Тогда тихая авторизация не сработает. Однако, поскольку тихая авторизация указана, сервер авторизации совершит переадресацию без участия пользователя на указанную в параметре redirect_uri локацию URI, добавив сообщение об ошибке в качестве параметра URL вместо кода авторизации.

Проблемы безопасности и последствия​

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

• Обход фильтра SSRF: Злоумышленники могут обходить фильтры, ограничивающие домены в запросах от пользовательских URL, что потенциально может привести к атакам типа SSRF (Server-Side Request Forgery — “серверная подделка запроса”).
• XSS (межсайтовый скриптинг): Эта проблема не такая частая, но, если на сервере авторизации настроен написанный на JavaScript механизм перенаправления с клиентской стороны, а введенная пользователем локация URI не фильтруется, в некоторых реализациях злоумышленник может добиться выполнения произвольного JavaScript-кода в контексте сервера авторизации.
• Фишинг и социальная инженерия: Хотя серьезность последствий часто оспаривается, факт остается фактом: пользователи могут быть перенаправлены на фишинговые сайты, что может привести к краже учетных данных или другим мошенническим действиям. Существуюют и более масштабные сценарии — например, цепочка с уязвимостью в виде диплинков: там использование открытого перенаправления для открытия ссылки может вызвать системное сообщение, что приложение “Пример” запрашивает открыть пример.com, а не хакер.com.

Стоит отметить, что я не упоминаю кражу учетных данных OAuth, так как мои тесты показали, что из-за поведения с параметрами URL маловероятно, что сервер авторизации передаст параметр code на адрес назначения злоумышленника.

Меры предотвращения​

На тему безопасности OAuth говорится, хоть и несколько расплывчато, в проекте Internet Engineering Task Force:

«Сервер авторизации ДОЛЖЕН принимать меры для предотвращения этих угроз. Сервер авторизации ДОЛЖЕН всегда авторизовать пользователя первым и, за исключением сценариев тихой авторизации, при необходимости запрашивать у него учётные данные до перенаправления. Оценив риски, сервер авторизации должен принять решение, можно доверять URI перенаправления или нет. Можно учитывать аналитику URI, выполненную внутренне или через внешнюю службу, чтобы оценить достоверность и надежность содержимого за URI, источник URI переадресации и прочие данные клиента».

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