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

Ключевые слова: авторизация, протокол, OAuth, токен, уязвимость, API-интерфейс, сервер, URL, HTTP, владелец ресурса, сервер ресурса, процедура аутентификации, запрос.

OAuth — открытый протокол для безопасной авторизации и доступа к защищенным ресурсам. Протокол позволяет проходить регистрацию без указания логина и пароля в Facebook, Google, Twitter а также во многих ИС использующихся в высших учебных заведениях Казахстана. Подобная схема используется в мобильных устройствах и приложениях. Особое внимание разработчики протокола уделяют уязвимости в OAuth, которые, как правило, связаны с конфигурацией и появляются в результате ошибок при реализации. Такие уязвимости в начале 2020 года в связи с массовым переходом на дистанционное обучение стали головной болью во многих учебных заведениях Казахстана.

Принцип работы OAuth

При использовании OAuth при аутентификации участвуют:

– владелец интернет-ресурса — пользователь, использующий протокол OAuth для входа;

– сервер интернет-ресурса — сторонний API-интерфейс, на котором происходит аутентификация пользователя;

– клиент — стороннее приложение с доступом к информации на сервере, которое использует владелец ресурса.

При аутентификации с OAuth клиент запрашивает разрешение на доступ к информации о нём у сервера ресурса. При этом приложение может получать как полную информацию, так и частичную. Например, пользователи Facebook указывают e-mail, public_profile, user_friends и другие данные. Если выдать клиенту только e-mail, то он не сможет получить доступ к профилю.

Вот как выглядит алгоритм первого входа в стороннее приложение с использованием Facebook:

1. Пользователь открывает нужную страницу клиента и нажимает «Войти через Facebook».
2. Клиент отправляет запрос к конечной точке аутентификации, например через страницу Google.
3. В ответ на запрос клиент перенаправляется на сервер ресурса с использованием кода 302.
4. Клиент идентифицируется на сервере ресурса с помощью уникального значения.
5. Возвратный URL (redirect_uri) определяет, куда сервер должен отправить браузер владельца после прохождения аутентификации.
6. Определяется тип возвращаемого ответа: код или токен.
7. Пользователь получает доступ к информации на сервере ресурса.

При первом входе владельцу ресурса показывается диалоговое окно, в котором содержится информация о запрашиваемых областях видимости и согласии на запрос. При следующей попытке входа клиент может напрямую обращаться к Facebook за нужной информацией. Процедура OAuth считается завершенной. Диалоговые окна при повторном входе не появляются, и владелец ресурса не знает о взаимодействии клиента с API-интерфейсом, т. к. процедура аутентификации выполняется в фоновом режиме. Это взаимодействие можно наблюдать только при мониторинге запросов HTTP. Такой принцип работы OAuth ставит перед всеми участника процедуры, и в первую очередь, перед владельцем ресурса, вопрос об уязвимости, которая напрямую зависит от одобренных областей видимости, связанных с токеном. Как это работает? Рассмотрим на примере знакомых нам ресурсов.

Похищение токенов доступа Facebook

Уязвимость обнаружил эксперт по вопросам безопасности Филипп Хэрвуд в 2016 г. Эксперт поставил перед собой цель: похитить токен пользователя социальной сети и получить доступ к информации на его странице, в том числе к конфиденциальным данным.

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

Процедура получения токена выполнялась при помощи фоновых запросов HTTP. Таким образом, открыв этот URL-адрес для аутентификации, пользователь перенаправлялся на страницу, которая содержала токен: http://REDIRECT_URI/#token=токен/.

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

Эксперимент Хервуда говорит о том, что при поиске уязвимости следует обращать внимание на приложения, о которых владельцы сайта просто забыли. В некоторых случаях это могут быть CNAME-записи для поддоменов, библиотеки JavaScript и пр.

Похищение токенов для входа на Microsoft

Немного сложнее похитить токены пользователей для входа на сайт Microsoft. На сайте не реализована процедура аутентификации с использованием протокола OAuth, но там применяется похожий процесс перенаправления. Джек Уиттон в 2016 г. нашел способ похитить токены, используемые при аутентификации. Для этого он использовал способность приложения передавать разные виды URL.

Как это работает? Пользователь заходит на сайт Microsoft и перенаправляется на страницу авторизации. При успешной авторизации по адресу внутри wreply отправляется запрос, ответ на который содержит токен. При этом попытка поменять wreply на другой домен приводит к ошибке. Джек Уиттон пробовал передавать символы с двойным кодированием, добавив в конец URL значение %252f. Специальные символы в этом адресе кодируются таким образом, что знак процента (%) превращается в косую черту(/). Когда Уиттон ставил вместо wreply полученный URL, то приложение вернуло ошибку с сообщением о некорректном адресе. Тогда взломщик добавил к домену хвост example.com и вместо ошибки получил URL со следующей структурой:

[// [имя_пользователя:пароль@]домен [:порт]] [/]путь [?запрос] [#фрагмент].

Домен, куда перенаправлялся пользователь, больше не выглядел как outlook.office.com., а значит, перенаправление можно выполнить к любому домену, который контролирует взломщик.

Джек Уиттон отметил, что причина уязвимости в этом случае — выполнение сайтом декодирования и проверки URL в два этапа. На первом этапе проверяется корректность доменного имени и соответствие структуре URL. Адрес с хвостом example.com успешно проходит проверку, т. к. воспринимается как корректное имя пользователя. На втором этапе сайт декодирует URL, изменяя фрагмент (знак %).

Таким образом, сайт Microsoft проверил структуру адреса, декодировал его и подтвердил присутствие в белом списке. При этом в качестве ответа на запрос возвращался URL, декодированный один раз, т. е. при посещении этого адреса токен жертвы отправляется сайту example.com, который контролирует взломщик. Используя полученный токен, Уиттон смог получить доступ к учетным записям пользователей Microsoft.

Похищение токенов для Slack

Похитить токены для корпоративного мессенджера Slack оказалось значительно проще. Дело в том, что самая распространенная уязвимость в OAuth появляется, если разработчик неправильно настраивает параметры возвратного URL, давая возможность взломщику получить токены. Эксперт в области ИТ-безопасности Прахар Прасад выявил способ обойти ограничения в разрешенном адресе для Slack путем добавления к нему любых значений. Эксперт установил, что мессенджер проверял только начало параметра redirect_uri. При этом, когда разработчик регистрировал новое приложение для Slack и добавлял его в белый список, взломщик мог расширить этот адрес и добиться перенаправления в любое место.

Для использования этого способа хакеру нужно просто создать подходящий поддомен на своем ресурсе. Когда жертва откроет зараженный URL сервера Slack, токены будут переданы на сайт злоумышленника. В свих исследованиях Прахар Прасад пошел еще дальше: он инициировал запрос от имени жертвы, встроив во вредоносную страницу тег . В результате взломщик получил возможность автоматически сделать запрос HTTP при каждом отображении страницы.

Выводы

Основные уязвимости открытого протокола OAuth это:

1. Приложения, неиспользуемые владельцем ресурса.
2. Поэтапная аутентификация.
3. Недостаточно строгая проверка возвратного URL.

Тем не менее, процедура аутентификации с использованием OAuth на сегодняшний день считается стандартизированной и используется повсеместно. Однако разработчики могут допустить ошибку, которая позволит взломщикам получить токены для авторизации. Исходя из этого, можно дать пользователям только один совет: используя приложения с поддержкой протокола OAuth, внимательно изучайте возвратный redirect_uri и попытайтесь определить корректность приложения при отправке токенов. Хакерам тоже можно дать совет: ищите нестандартные способы аутентификации на основе OAuth и приложения, о которых забыли разработчики.

Соокращения

ИС — информационная система

Термины иопределения

OAuth — открытый протокол для безопасной авторизации и доступа к защищенным ресурсам.

Уязвимость — Недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который (которая) может быть использована для реализации угроз безопасности информации.

Литература:

1. Яворски П. Ловушка для багов. Полевое руководство по веб-хакингу — Питер, 2020.
2. Сикорски М., Хониг Э. Вскрытие покажет! Практический анализ вредоносного ПО — Питер, 2018.
3. Скабцовс Н. В. Аудит безопасности информационных систем — Питер, 2018.
4. Эриксон Д. Хакинг: искусство эксплойта. 2-е изд. — Питер, 2021.