Исследование безопасности современных веб-технологий единого входа (Выпускная квалификационная работа) (стр. 2 )

Основная идея, заложенная в OAuth — дать стороннему приложению ограниченный доступ к данным пользователя, которые хранятся удаленно на сервере, при этом не раскрывая учетные данные пользователя к этому серверу или сайту. Иначе говоря, основное предназначение OAuth это именно процесс авторизации. OAuth сегодня существует в виде двух версий: OAuth 1 и OAuth 2. Обе из них основаны на передаче третьей стороне для доступа к данным специального токена - случайно сгенерированной строки, которую стороннее приложение предоставляет серверу для доступа к тем данным, к которым приложению позволен доступ. Этот же токен, подобно ключу от замка, может выступать одновременно и как доказательство того, что пользователь является тем, за кого себя выдает. Для простоты мы будем относить OAuth к протоколам аутентификации, или технологиям единого входа, поскольку он действительно часто используется в таком качестве помимо поддержки авторизации. Согласно стандартам, сообщения и учетные данные в OAuth передаются с помощью HTTP-перенаправлений браузера с домена провайдера на домен клиента так, что данные при этом добавляются в URL после перенаправления. Часто в качестве перенаправлений используются HTTP-ответы с кодом 302.

Рисунок 1. Аутентификация с помощью OAuth

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

Вторая версия, изложенная в RFC 6749, недавно получила статус предложенного стандарта (proposed standard) и используется многими крупными сервис-провайдерами [25]. В то же время, эта версия была раскритикована за неудачные решения, принятые при проектировании [26]. Более того, последний вариант стандарта OAuth 2 определяет его вовсе не как протокол, а как фреймворк для построения протоколов, что вполне отражает общую тенденцию реализовывать OAuth 2 совершенно по-разному в каждом отдельном случае так, что два протокола двух разных провайдеров, выполненные по одинаковому стандарту или лишь слегка отходя от него, оказываются не совместимы друг с другом. Во второй версии OAuth описаны способа авторизации: с помощью кода авторизации (code grant flow) и с помощью токена (implicit grant flow). Первый способ является основным и надежен как для авторизации, так и для аутентификации, а второй, менее безопасный, предполагается использовать в легковесных браузерных приложениях.

При авторизации через токен (implicit) пользователь направляется на страницу провайдера, чтобы подтвердить или отклонить запрос приложения на доступ к данным. После разрешения доступа провайдер генерирует токен и перенаправляет браузер пользователя на заранее заданный redirect_uri на домене приложения, передавая сам токен в качестве параметра URL.

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

OpenID изначально был создан как метод, позволяющий удостоверить личность пользователя по запросу какого-либо приложения или сервиса, то есть, для поддержки аутентификации.

Рисунок 2. Аутентификация с помощью OpenID

Аутентификация с помощью OpenID начинается с фазы, когда провайдер и клиент (или Relying Party) договариваются об общем ключе для заданной сессии. После этого пользователь направляется на сайт провайдера для подтверждения запроса на аутентификацию, и в случае успеха его браузер перенаправляется на клиентский URL, заданный заранее с помощью параметра openid. return_to, куда передаются данные пользователя, подписанные провайдером на общем с клиентом ключе.

1.2 Общие принципы OAuth и OpenID

Работа OAuth и OpenID, так же как и некоторых других веб-протоколов аутентификации, основана на перенаправлениях, или редиректах браузера с помощью ответов с кодом 302: благодаря ним происходит согласованный переход управления с клиента на провайдера и обратно, с помощью них также передаются учетные данные с одного домена на другой. Очевидно, что целостность и защищенность такого канала во многом определяет и защищенность всего протокола. В подтверждение этому, именно манипуляция параметром redirect_uri при перенаправлениях в протоколе Facebook OAuth позволяла эксплуатировать огромное количество уязвимостей [6, 10-15].

При защите SSO-протоколов в первую очередь требуется избежать возможности утечки учетных данных либо их модификации третьей стороной. Общей и известной проблемой для многих протоколов при этом являются Open redirect'ы, наличия которых на домене клиента в некоторых условиях достаточно, чтобы полностью обойти аутентификацию [27, 28].

Следуя OWASP, Open redirect является уязвимостью и определяется как приложение, которое принимает адрес в качестве параметра и перенаправляет клиента по адресу без каких-либо проверок [33]. Как правило, имеется в виду перенаправление с помощью кода 302, однако можно объединить под этим понятием сразу несколько возможных случаев, когда браузер пользователя направляется по указанному адресу, каждый из которых может представлять опасность для приложений и SSO-протоколов: Open forward, открытие окна, создание фрейма или отправка формы.

С другой стороны, конечные точки SSO-протоколов работают по такому же принципу, принимая адрес для перенаправления из параметров openid. return_to, redirect_uri либо oauth_callback. В некотором смысле конечные точки SSO-провайдеров как раз реализуют Open redirect, поскольку атакующий может отправить браузер пользователя по любому адресу, предварительно зарегистрировав свое клиентское приложение и назначив ему необходимые адреса для перенаправления.

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

1.3 Методология исследования безопасности SSO-технологий

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

После этого в работе делается промежуточный шаг и определяются 4 модели логина, описывающие возможные варианты работы SSO-сервисов в виде, удобном для последующего детального анализа безопасности.

Затем для исследования возможных атак дается краткая схема для аудита приложений и сервисов. Следуя этой схеме, рассматривается каждая из четырёх моделей с точки зрения безопасности и делается предположение, какого вида атаки возможны в рамках этой модели и при каких условиях. При этом, мы не ограничиваемся только атаками на сам протокол: атаки на приложение с выполнением кода, а тем более на сервисы провайдера как правило предпочтительнее для атакующего, если возможны. После этого мы пробовали реализовать каждую из атак, взяв для этого подходящее приложение или сервис. Для успешной атаки кроме самих уязвимостей в стандартах каждый раз нам требовалось дополнительно еще несколько багов, тем не менее, во всех четырех случаях удавалось их отыскать.

В качестве модели атакующего в работе была взята модель веб-атакующего (web-attacker) [29]. В таких условиях атакующий может создать свой сайт и зарегистрировать приложение-клиент какого-либо сервис-провайдера, но сам он не может выступать в роли провайдера OAuth или OpenID. Считается, что атакующий может заставить жертву кликнуть по его ссылке или зайти на его сайт, но при этом жертва не будет авторизовывать ни одно его приложение, исключая лишь два случая, в которых наша атака требовала от пользователя авторизовать вредоносное приложение с минимально возможным набором разрешений, что может соответствовать, например, запросу на авторизацию онлайн-игры или аутентификации на неизвестном сайте с помощью своего OpenID-провайдера. Не рассматриваются любые атаки с использованием фишинга, кликджекинга или социальной инженерии. Атакующий не имеет доступа ни к сети жертвы, ни к одному из его устройств или учетных записей.

Для изучения внутреннего устройства сервисов, протоколов, клиентских приложений использовалась документация, исходный код или реверс, в зависимости от того, что было доступно. В противном случае, модуль или сервис исследовался как черный ящик (например, серверные скрипты провайдера). В работе не были использованы никакие автоматизированные инструменты или динамические методы анализа кроме пошагового отладчика для кода и сетевого отладчика для пакетов по двум причинам: во-первых, автоматизированные инструменты вряд ли пригодны в случае поиска новых техник для атак, во-вторых, такой набор инструментов обязательно есть у каждого разработчика либо у возможного атакующего.  В работе также не используется никаких методов формального анализа и верификации, поскольку был выбран противоположный подход для исследования, учитывающий реальные условия, в которых работает протокол. Моделирование в таком случае было бы неоправданно трудоёмким, если вообще возможным.