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

1.4 Анализ SSO-технологий нескольких крупных провайдеров

Для анализа было выбрано несколько протоколов крупных сервис-провайдеров, в числе которых Google OpenID 2 и несколько OAuth-протоколов:  Facebook OAuth 2, Google OAuth 2 и Microsoft Live Connect OAuth 2. Затем они были исследованы по следующим параметрам (Таблица 1):

Поддерживаемый кросс-доменный транспорт Возможность автоматического перенаправления Вариативность параметра redirect_uri Домены, на которых доступны конечные точки протоколов

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

Сервис	Поддерживаемый кросс-доменный транспорт	Параметр для авто-перенаправления запроса	Вариативность redirect_uri	Домены конечных точек
Facebook OAuth 2	Redirect, postMessage, Flash, Fragment	display=none	static domain*	, www. , graph.
Google OAuth 2	Redirect, postMessage, Fragment***, Cookie	immediate=true	static, tail**, subdomains**	www. , accounts.
Google OpenID 2	Redirect	openid. mode= checkid_immediate	tail	www. , accounts.
Microsoft Live Connect OAuth	Redirect	display=none	static domain***	login.
* Была недавно заменена на более строгую проверку "tail" ** Только для перенаправления сообщений об ошибках в режиме immediate *** Fragment (rmr) был целиком удален из Google API после того, как мы сообщили об уязвимости в нем **** Поддомены разрешены

Таблица 1. Сравнение технологий SSO некоторых провайдеров

1.4.1 Кросс-доменный транспорт

В первом столбце таблицы перечислены основные каналы передачи данных от провайдера к клиенту, что в контексте веб-протоколов фактически является кросс-доменной передачей данных в браузере. OAuth и OpenID по документации используют для обмена данными только перенаправления (Redirects). Но кроме перенаправлений широко используются и другие способы, главным из которых является PostMessage — специальный метод из HTML5 для безопасного обмена сообщениями между двумя разными доменами. Flash уже является устаревшим способом, который использовался до распространения PostMessage API. При этом флеш-объекты внедряется в оба окна и связываются для обмена данными через собственный механизм LocalConnection Flash API [31]. Другой устаревший транспорт Fragment, который вместе с Flash ещё используется, но во многом лишь для обратной совместимости, устроен так, что передаваемое другому домену сообщение устанавливается в URL Fragment вспомогательного окна или фрейма, откуда оно вместе с полным URL уже доступно для чтения всем в пределах домена. Под термином Fragment объединено несколько вариаций такого метода, например, rmr или ifpc, используемые в Google API и библиотеке Shindig [32]. Cookie обозначает усиленную версию протокола OAuth с кодом авторизации, который передается через заголовок Set-Cookie вместо URL.

Очевидно, что описанные в стандартах перенаправления (Redirects) используются как транспорт абсолютно всеми протоколами, и это видно в Таблице 1. PostMessage, Fragment и Flash являются вспомогательными механизмами, которые в основном используются для различных сложных веб-приложений на клиентской стороне в рамках соответствующего варианта реализации OAuth. Такие транспорты, впрочем, описывают передачу данных только на клиентской стороне, перед этим данные запрашиваются с сервера и передаются на вход Javascript-обработчика в браузере либо с помощью  редиректов, либо с помощью XMLHttpRequest-запроса  (XHR). При этом, OpenID-приложения не используют сложных вариантов транспорта, полагаясь только на редиректы (Redirects). Усиленный Cookie-транспорт из всех рассмотренных SSO-сервисов используется только браузером Google Chrome в процессе входа в учетную запись пользователя для синхронизации, а его аутентификация построена целиком на Google OAuth 2.

1.4.2 Автоматические перенаправления

Каждый запрос в рамках OpenID для подтверждения подлинности пользователя, а так же каждый запрос на авторизацию с помощью OAuth может быть направлен пользователю явно для подтверждения в виде окна или диалога, а может быть и обработан автоматически, если запрос клиента был разрешен ранее. Интересно заметить, что абсолютно все рассмотренные SSO-сервисы при этом поддерживают специальный флаг, указывающий провайдеру, что запрос следует перенаправить с помощью редиректа в любом случае, даже если запрос еще не подтвержден (перенаправить с сообщением ошибки). Такой параметр предусмотрен для некоторых случаев, когда требуется очень быстро и без участия пользователя узнать, подтвержден ли запрос, и сразу получить токен в случае успеха. Подобное поведение описано в стандарте OpenID, но оно указано ни в какой из версий OAuth, однако из Таблицы 1 видно, что и OAuth-провайдеры тоже используют этот флаг.

Фактически это значит, что внедрение SSO-протокола, поддерживающего такой флаг, приводит к появлению Open Redirect'а [33, 34], что считается уязвимостью средней критичности. Атакующему достаточно лишь зарегистрировать своего SSO-клиента и адрес для перенаправления, а затем сконструировать URL для запроса на авторизацию. Широко известны проблемы, связанные с небезопасностью сосуществования SSO-протоколов вместе с Open Redirect'ами [28, 35, 36], однако SSO-протоколы реализуют возможность Open Redirect'а сами по себе из-за своих особенностей.

1.4.3 Вариативность параметра redirect_uri

Выполняя запрос на аутентификацию или авторизацию, клиент указывает свой URL, куда провайдер направит браузер после обработки запроса. В случае OAuth это oauth_callback/redirect_uri, а в OpenID такой параметр openid. return_to. Как правило, redirect_uri должен совпадать с заранее указанным в настройках клиента значением для надежности, но иногда разработчиками протокола используются менее строгие проверки. Мы сравнили каждый SSO сервис по тому, насколько строгая осуществляется проверка redirect_uri: чем более строгая проверка, тем менее уязвим протокол. Facebook использовал проверку на уровне static domain, позволяя использовать URL в пределах зарегистрированного домена или любых его поддоменов и оставляя таким образом много возможностей для атак, впоследствии эта проверка была заменена на более строгую типа tail, как и у Google OpenID, когда redirect_uri должен начинаться с зарегистрированного значения, позволяя перенаправления лишь на URL с дочерними путями или с дополнительными параметрами в строке запроса. Наиболее строгая проверка static в OAuth от Google, которая пропускает только URL, полностью идентичный зарегистрированному, хотя при этом возможно ретранслировать сообщения об ошибках на все поддомены (subdomains) и на все дочерние пути (tail). Microsoft OAuth принимает все URL, которые находятся на том же домене или любом поддомене.

1.4.4 Домены конечных точек

Иногда отдельные части веб-сервисов, потенциально небезопасные или содержащие пользовательский контент выносятся на собственные поддомены, либо вообще на специальные изолированные домены, подобно тому, как перевод страницы в Google Translate отображается через специальный домен-песочницу . Последний критерий, по которому SSO-провайдеры были рассмотрены в работе, показывает местоположение конечных точек каждого протокола, и оказывается, что SSO-сервис приходится всегда размещать на самом важном поддомене провайдера, связанном c учетной записью пользователя SSO: например, оба SSO-протокола от Google вынесены на accounts. . Вероятно, это связано с тем, что прежде чем авторизовать или отказать в запросе, конечная точка протокола обязана знать, какой именно пользователь прислал запрос, то есть знать его Cookie с идентификатором его сессии. В таком случае, SSO-протоколы реализуют возможность Open redirect'а на самых важных поддоменах провайдера из всех возможных, что гораздо значительнее, чем, например, open redirect на домене сервиса для сокращения ссылок провайдера.

1.5 Модели логина

Исследование возможных применений open redirect'ов SSO-протоколов в целом было бы не очень удобно из-за того, что приложения, использующие единый вход, сильно различаются между собой, как, например, веб-приложения и нативные программы. Вместе с этим, реализации протокола тоже различные для различных типов приложений. Очевидно, что и в стандартах OpenID и OAuth тоже даются классификации приложений [1]. Для исследования работы перенаправлений они неудобны тем, что не учитывают используемый транспорт, то есть, то, какие именно типы перенаправлений используются. Поэтому далее мы определим 4 различных сценария работы SSO-протокола, основываясь на том, через какой транспорт передаются сообщения.

1.5.1 Стандартная модель

Приложения первого типа являются веб-приложениями либо браузерными приложениями и используют для передачи данных только сами перенаправления HTTP, либо обычные HTTP-запросы, следуя стандартам OAuth либо OpenID. К примеру, к этой группе относятся authorization grant flow из OAuth 2, а также implicit flow, если в последнем не используются никакие прокси-iframe для передчи токенов. В то же время OAuth-клиент может использовать скрипты и sdk от сервис-провайдера, если они исполняются на домене клиента.

1.5.2 Прокси-модель

Следующая группа включает веб-приложения и браузерные приложения, использующие для получения данных на клиентской стороне специальные прокси-окна (iframe). Прокси, исполняемый на домене провайдера, получает данные от провайдера и передает их на стороне браузера нужному клиенту, используя различные механизмы вроде postMessage API, Flash и других. Такой подход используется не только для браузерных приложений, но и для веб-приложений с серверной частью: тогда учетные данные, полученные от прокси, передаются с клиентской стороны на сервер для дальнейшей работы. При этом прокси-фрейм не предназначен для выполнения API-запросов на сервер.