Лабунец

РОССИЙСКАЯ ФЕДЕРАЦИЯ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК
КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности
д.т.н. профессор
А.А. Захаров
(подпись)
«___» ________20__ г.
Лабунец Андрей Геннадьевич
ИССЛЕДОВАНИЕ БЕЗОПАСНОСТИ СОВРЕМЕННЫХ ВЕБТЕХНОЛОГИЙ ЕДИНОГО ВХОДА
(Выпускная квалификационная работа)
Научный руководитель:
доцент
/И.О. Фамилия/
(подпись)
Автор работы:
/И.О. Фамилия/
(подпись)
Тюмень – 2014
Оглавление
Оглавление ............................................................................................................... 2
Введение ................................................................................................................... 3
1. Исследование безопасности SSO-технологий ................................................. 8
1.1 Обзор стандартов OAuth и OpenID ............................................................. 8
1.2 Общие принципы OAuth и OpenID ........................................................... 11
1.3 Методология исследования безопасности SSO-технологий .................. 13
1.4 Анализ SSO-технологий нескольких крупных провайдеров.................. 15
1.4.1 Кросс-доменный транспорт ................................................................ 16
1.4.2 Автоматические перенаправления ..................................................... 17
1.4.3 Вариативность параметра redirect_uri ............................................... 18
1.4.4 Домены конечных точек ...................................................................... 18
1.5 Модели логина ............................................................................................. 19
1.5.1 Стандартная модель ............................................................................. 20
1.5.2 Прокси-модель...................................................................................... 20
1.5.3 Модель Контроллер ............................................................................. 20
1.5.4 Нативная модель .................................................................................. 21
2 Атаки на некоторые SSO-сервисы и клиенты ................................................. 22
2.1 Стандартная модель .................................................................................... 22
2.2 Прокси-модель............................................................................................. 23
2.3 Модель Контроллер .................................................................................... 24
2.4 Нативная модель ......................................................................................... 25
Заключение ............................................................................................................ 27
Список литературы ............................................................................................... 28
2
Введение
OAuth [1] и OpenID [2] являются наиболее известными сегодня
стандартами единого входа (Single sign-on, SSO) для пользователей вебсервисов, каждый из которых имеет свою долгую историю и закреплен в
соответствующем стандарте или RFC документе (OAuth). В середине 2000ых их появлению и развитию способствовала интеграция большого
количества сервисов между собой и в рамках www, и в рамках внутренних
корпоративных информационных систем: хотелось иметь, во-первых,
единую учетную запись для входа сразу во все сервисы, во-вторых, единый
механизм для предоставления доступа к своим данным на сайтах или
сервисах. OpenID считается одним из самых известных и надежных решений
для единого входа, а OAuth, предназначенный изначально только для
авторизации на доступ к клиентским данным, фактически используется ещё и
как технология единого входа тоже.
Актуальность темы дипломной работы определяется возросшей
ролью открытых стандартов SSO и значительным количеством серьезных
уязвимостей, до сих пор обнаруживаемых регулярно у крупных OpenID- и
OAuth-провайдеров.
Аутентификация
через
Facebook
или
GoogleID
постепенно начинает дополнять или полностью заменять обычный вход на
многих сайтах, а поддержка OAuth в течение последних лет появляется ещё и
у приложений, сильно отличающихся от веб-сервисов средой исполнения: в
нативных программах и мобильных платформах. При этом, например, в
случае Facebook за 2012-ый год можно заметить всего около 4 публикаций о
более или менее значимых проблемах безопасности в их протоколе OAuth [69], в 2013-ом же году в открытом доступе уже около 7 различных статей [1016]. Одна из недавних серьезных академических публикаций [8] показывает,
как исследователи смогли обойти аутентификацию сразу нескольких
3
основных сервис-провайдеров. Ни одно из перечисленных исследований при
этом не объясняет природу появления множества различных ошибок
реализации OpenID или OAuth, а также не рассматривает защищенность
самих приложений в целом, как правило сосредотачиваясь либо на изучении
абстрактных моделей и уже хорошо известных атак, либо на поиске
различных уязвимостей в каждой отдельной реализации протокола в отрыве
от их общих принципов и от особенностей систем в целом. Вопрос о том,
содержат ли указанные технологии какие-либо уязвимости, которые трудно
или вообще невозможно исправить, является открытым. Для ответа на этот
вопрос необходимо рассмотреть общие принципы и базовые механизмы
таких протоколов с точки зрения безопасности, при этом обязательно
учитывая реальные условия, среду исполнения и особенности приложений.
Степень разработанности проблемы. Важно, что оба исследуемых
стандарта описывают ключевые механизмы безопасности, внедряемые в
приложения и сервисы: найденные злоумышленником слабости только в
аутентификации или в авторизации сразу могут дать ему возможность
скомпрометировать систему напрямую, например, просто получив доступ к
необходимым данным, минуя другие атаки и этапы. Кроме этого, очевидно,
что если у сервис-провайдера уязвима технология SSO, то под угрозой
оказываются сразу все клиенты такого провайдера, поэтому баги таких
протоколов у крупных провайдеров ценны и интересны с точки зрения
атакующего, а возможные уязвимости уже внутри самих стандартов —
невероятно дороги и, к счастью, крайне редки [17, 18]. Благодаря таким
особенностям OAuth и OpenID стали одним из основных ядер, вокруг
которого
концентрируются
исследования
по
безопасности
как
с
академической стороны (криптография, формальный анализ, проверка
моделей, приватность и защита персональных данных) [20-23, 30], так и со
стороны независимых исследований (ручной анализ, техники новых атак) [7,
8, 14, 16]. Говорить о гарантированно безопасном протоколе можно лишь в
4
рамках какой-то модели, и при этом можно действительно обеспечить
защищенность самого протокола [20, 23]
при соблюдении необходимых
рекомендаций из модели угроз [24]. Однако любая модель как минимум
неполна по сравнению с конкретной реализацией этого протокола и не может
дать больше, чем в эту модель изначально заложено (возможные атаки,
уровень абстракции), и кроме этого может быть неточна. По этой причине,
подобно какому-либо давно используемому криптографическому примитиву,
формально не доказанная безопасность которого требует регулярных
проверок от криптоаналитиков, научным сообществом точно так же негласно
поощряется
постоянный
поиск
проблем
безопасности
стандартов
и
технологий SSO, новых атак на них и способов защиты, а также методов их
исследования. Рассмотрение безопасности технологий SSO с учётом
особенностей приложений и сред исполнения может позволить обнаружить
ранее неизвестные направления для атак. При этом, исследование
безопасности общих базовых механизмов таких технологий потенциально
может выявить наиболее серьезные проблемы, актуальные сразу для
огромного количества различных протоколов и приложений.
Цель дипломной работы состоит в исследовании безопасности
современных технологий единого входа.
Задачи дипломной работы:
 На основе анализа стандартов SSO выделить слабые места SSOтехнологий
 Проанализировать протоколы нескольких основных сервис-провайдеров,
исследовав найденные слабые места и возможности для их эксплуатации
 Предложить классификацию SSO-протоколов, удобную для дальнейшего
анализа
 Исследовать возможности для эксплуатации найденных проблем SSOтехнологий в каждой группе, предложить возможные атаки с их
использованием
5
 Экспериментально проверить практическую осуществимость
предложенных атак
Объектом исследования в дипломной работе является защищенность
SSO-технологий на основе на основе OpenID и OAuth.
Предметом исследования выступает безопасность механизмов обмена
данными OpenID и OAuth, а также основанные на таких механизмах техники
эксплуатации уязвимостей.
Методологической и теоретической основой дипломной работы
явились стандарты исследуемых протоколов, их модели угроз, публикации
работ
по
безопасности
моделирования,
анализа
SSO-технологий,
и
верификации
методам
формализации,
протоколов.
Дипломное
исследование также во многом опирается на опубликованные баг-репорты и
описания обнаруженных уязвимостей рассматриваемых протоколов.
Теоретическая значимость состоит в развитии методов исследования
безопасности протоколов SSO и защищенности систем, их использующих.
Практическая значимость определяется тем, что в ходе работы
удалось
обнаружить
и
устранить
множество
серьезных
проблем
безопасности в крупных продуктах Google, Facebook, Foursquare и других
компаний. Кроме этого, исследование демонстрирует эффективные методы
обнаружения, эксплуатации и устранения ранее неизвестных уязвимостей,
позволяя с помощью этих методов повысить защищенность продуктов и
сервисов с технологиями SSO.
Новизна дипломной работы заключается в рассмотрении безопасности
базовых механизмов из веб-среды, задействованных всеми современными
технологиями SSO, с учётом особенностей различных программных
продуктов и сред, где такие технологии используются.
Наиболее
существенные результаты, полученные в процессе
исследования, состоят в следующем:
 Выявлены фундаментальные проблемы безопасности SSO-протоколов
6
 Показаны новые виды атак на популярные приложения с использованием
выявленных слабостей
 Дана классификация SSO-приложений, в контексте которой предложены
методы для обнаружения уязвимостей, связанных с особенностями
технологий SSO
7
1. Исследование безопасности SSO-технологий
1.1 Обзор стандартов OAuth и OpenID
Главная мысль при создании протоколов OAuth и OpenID — избавить
пользователя от запоминания сотен разных паролей и учетных записей к
каждому необходимому сервису, а так же позволить авторизовывать
сторонние приложения для доступа к своей учетной записи и данным, не
раскрывая пароля или других секретов. Для этого OpenID-провайдер
удостоверяет личность пользователя с помощью подписанного сертификата,
а сервер авторизации OAuth передает токен для доступа к пользовательским
данным, при этом используя усовершенствованную версию схемы с токеном
ещё и для единого входа.
Протоколы на основе OpenID и OAuth задумывались прежде всего для
веб-приложений и сайтов, и поэтому работают поверх веб-стека, то есть,
являются веб-протоколами, работающими над HTTP и внутри браузера, в
отличие, к примеру, от таких протоколов аутентификации, как Kerberos,
который использует в качестве транспорта непосредственно TCP или UDP.
Несмотря на привязку к веб-технологиям, оба стандарта используются даже в
тех системах, которые не являются веб-приложениями или сайтами в чистом
виде, например, для аутентификации нативных программ [3], в мобильных
платформах [4] и в корпоративных приложениях [5].
Основная идея, заложенная в OAuth — дать стороннему приложению
ограниченный доступ к данным пользователя, которые хранятся удаленно на
сервере, при этом не раскрывая учетные данные пользователя к этому
серверу или сайту. Иначе говоря, основное предназначение OAuth это
именно процесс авторизации. OAuth сегодня существует в виде двух версий:
OAuth 1 и OAuth 2. Обе из них основаны на передаче третьей стороне для
доступа к данным специального токена - случайно сгенерированной строки,
которую стороннее приложение предоставляет серверу для доступа к тем
8
данным, к которым приложению позволен доступ. Этот же токен, подобно
ключу от замка, может выступать одновременно и как доказательство того,
что пользователь является тем, за кого себя выдает. Для простоты мы будем
относить OAuth к протоколам аутентификации, или технологиям единого
входа, поскольку он действительно часто используется в таком качестве
помимо поддержки авторизации. Согласно стандартам, сообщения и учетные
данные в OAuth передаются с помощью HTTP-перенаправлений браузера с
домена провайдера на домен клиента так, что данные при этом добавляются в
URL
после
перенаправления.
Часто
в
качестве
перенаправлений
используются HTTP-ответы с кодом 302.
Рисунок 1. Аутентификация с помощью OAuth
Первая версия стандарта не является устаревшей и существенно
отличается от второй. В первой версии OAuth приложению сначала нужно
через backend-запрос зарегистрировать у провайдера oauth_callback URL и
получить от него взамен токен, назначенный для этого URL. Затем
приложение направляет браузер пользователя на домен провайдера, для того
чтобы одобрить этот токен для доступа к необходимым данным. В случае
успеха, браузер после этого переходит на oauth_callback URL, завершая
авторизацию.
9
Вторая версия, изложенная в RFC 6749, недавно получила статус
предложенного стандарта (proposed standard) и используется многими
крупными сервис-провайдерами [25]. В то же время, эта версия была
раскритикована за неудачные решения, принятые при проектировании [26].
Более того, последний вариант стандарта OAuth 2 определяет его вовсе не
как протокол, а как фреймворк для построения протоколов, что вполне
отражает общую тенденцию реализовывать OAuth 2 совершенно по-разному
в каждом отдельном случае так, что два протокола двух разных провайдеров,
выполненные по одинаковому стандарту или лишь слегка отходя от него,
оказываются не совместимы друг с другом. Во второй версии OAuth описаны
способа авторизации: с помощью кода авторизации (code grant flow) и с
помощью токена (implicit grant flow). Первый способ является основным и
надежен как для авторизации, так и для аутентификации, а второй, менее
безопасный, предполагается использовать в легковесных браузерных
приложениях.
При авторизации через токен (implicit) пользователь направляется на
страницу провайдера, чтобы подтвердить или отклонить запрос приложения
на доступ к данным. После разрешения доступа провайдер генерирует токен
и перенаправляет браузер пользователя на заранее заданный redirect_uri на
домене приложения, передавая сам токен в качестве параметра URL.
Авторизация через код отличается тем, что приложение тем же самым
способом сначала получает код авторизации, который затем обменивает на
токен через backend-запрос, предоставляя собственный секретный ключ. Эта
схема надежнее в том смысле, что кража кода сама по себе не даст
злоумышленнику доступ к данным пользователя, так как неизвестен
секретный ключ, чтобы обменять код на токен доступа.
OpenID изначально был создан как метод, позволяющий удостоверить
личность пользователя по запросу какого-либо приложения или сервиса, то
есть, для поддержки аутентификации.
10
Рисунок 2. Аутентификация с помощью OpenID
Аутентификация с помощью OpenID начинается с фазы, когда
провайдер и клиент (или Relying Party) договариваются об общем ключе для
заданной сессии. После этого пользователь направляется на сайт провайдера
для подтверждения запроса на аутентификацию, и в случае успеха его
браузер перенаправляется на клиентский URL, заданный заранее с помощью
параметра
openid.return_to,
куда
передаются
данные
пользователя,
подписанные провайдером на общем с клиентом ключе.
1.2 Общие принципы OAuth и OpenID
Работа OAuth и OpenID, так же как и некоторых других веб-протоколов
аутентификации, основана на перенаправлениях, или редиректах браузера с
помощью ответов с кодом 302: благодаря ним происходит согласованный
переход управления с клиента на провайдера и обратно, с помощью них
также передаются учетные данные с одного домена на другой. Очевидно, что
целостность и защищенность такого канала во многом определяет и
защищенность
всего
протокола.
В
подтверждение
этому,
именно
манипуляция параметром redirect_uri при перенаправлениях в протоколе
11
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, а так же возможностей их использования для атак.
12
1.3 Методология исследования безопасности SSO-технологий
Для исследования безопасности использования перенаправлений в
работе рассматриваются несколько протоколов аутентификации наиболее
крупных сервис-провайдеров. При этом сами протоколы, их реализации и
особенности среды для клиентских приложений изучаются и сравниваются
по нескольким параметрам, наиболее важным для понимания работы
редиректов в случае каждого протокола. На основе такого анализа делается
вывод о потенциальных слабостях, однако для дальнейшего исследования их
критичности и способов их эксплуатации приходится рассматривать
отдельно различные реализации протоколов, поскольку условия для
атакующего сильно отличаются в каждом случае.
После этого в работе делается промежуточный шаг и определяются 4
модели логина, описывающие возможные варианты работы SSO-сервисов в
виде, удобном для последующего детального анализа безопасности.
Затем для исследования возможных атак дается краткая схема для
аудита приложений и сервисов. Следуя этой схеме, рассматривается каждая
из четырёх моделей с точки зрения безопасности и делается предположение,
какого вида атаки возможны в рамках этой модели и при каких условиях.
При этом, мы не ограничиваемся только атаками на сам протокол: атаки на
приложение с выполнением кода, а тем более на сервисы провайдера как
правило предпочтительнее для атакующего, если возможны. После этого мы
пробовали реализовать каждую из атак, взяв для этого подходящее
приложение или сервис. Для успешной атаки кроме самих уязвимостей в
стандартах каждый раз нам требовалось дополнительно еще несколько багов,
тем не менее, во всех четырех случаях удавалось их отыскать.
В качестве модели атакующего в работе была взята модель вебатакующего (web-attacker) [29]. В таких условиях атакующий может создать
свой сайт и зарегистрировать приложение-клиент какого-либо сервис13
провайдера, но сам он не может выступать в роли провайдера OAuth или
OpenID. Считается, что атакующий может заставить жертву кликнуть по его
ссылке или зайти на его сайт, но при этом жертва не будет авторизовывать ни
одно его приложение, исключая лишь два случая, в которых наша атака
требовала от пользователя авторизовать вредоносное приложение с
минимально возможным набором разрешений, что может соответствовать,
например, запросу на авторизацию онлайн-игры или аутентификации на
неизвестном
сайте
с
помощью
своего
OpenID-провайдера.
Не
рассматриваются любые атаки с использованием фишинга, кликджекинга
или социальной инженерии. Атакующий не имеет доступа ни к сети жертвы,
ни к одному из его устройств или учетных записей.
Для изучения внутреннего устройства сервисов, протоколов, клиентских
приложений использовалась документация, исходный код или реверс, в
зависимости от того, что было доступно. В противном случае, модуль или
сервис исследовался как черный ящик (например, серверные скрипты
провайдера). В работе не были использованы никакие автоматизированные
инструменты или динамические методы
анализа кроме пошагового
отладчика для кода и сетевого отладчика для пакетов по двум причинам: вопервых, автоматизированные инструменты вряд ли пригодны в случае поиска
новых техник для атак, во-вторых, такой набор инструментов обязательно
есть у каждого разработчика либо у возможного атакующего. В работе также
не используется никаких методов формального анализа и верификации,
поскольку был выбран противоположный подход для исследования,
учитывающий
реальные
условия,
в
которых
работает
протокол.
Моделирование в таком случае было бы неоправданно трудоёмким, если
вообще возможным.
14
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,
Fragment
Flash,
display=none
static domain*
facebook.com,
www.facebook.com,
graph.facebook.com
Google OAuth 2
Redirect,
postMessage,
Fragment***, Cookie
immediate=true
static,
tail**,
subdomains**
www.google.com,
accounts.google.com
Google OpenID 2
Redirect
openid.mode=
checkid_immediate
tail
www.google.com,
accounts.google.com
Microsoft
Live
Connect OAuth
Redirect
display=none
static domain***
login.live.com
* Была недавно заменена на более строгую проверку "tail"
** Только для перенаправления сообщений об ошибках в режиме immediate
*** Fragment (rmr) был целиком удален из Google API после того, как мы сообщили об уязвимости в нем
**** Поддомены разрешены
Таблица 1. Сравнение технологий SSO некоторых провайдеров
15
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). При этом,
16
не
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], однако SSO17
протоколы реализуют возможность 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 Домены конечных точек
Иногда отдельные части веб-сервисов, потенциально небезопасные или
содержащие
пользовательский
контент
выносятся
на
собственные
18
поддомены, либо вообще на специальные изолированные домены , подобно
тому, как перевод страницы в Google Translate отображается через
специальный домен-песочницу googleusercontent.com. Последний критерий,
по которому SSO-провайдеры были рассмотрены в работе, показывает
местоположение конечных точек каждого протокола, и оказывается, что
SSO-сервис приходится всегда размещать на самом важном поддомене
провайдера, связанном c учетной записью пользователя SSO: например, оба
SSO-протокола от Google вынесены на accounts.google.com. Вероятно, это
связано с тем, что прежде чем авторизовать или отказать в запросе, конечная
точка протокола обязана знать, какой именно пользователь прислал запрос,
то есть знать его Cookie с идентификатором его сессии. В таком случае, SSOпротоколы реализуют возможность Open redirect'а на самых важных
поддоменах провайдера из всех возможных, что гораздо значительнее, чем,
например, open redirect на домене сервиса для сокращения ссылок
провайдера.
1.5 Модели логина
Исследование возможных применений open redirect'ов SSO-протоколов в
целом было бы не очень удобно из-за того, что приложения, использующие
единый вход, сильно различаются между собой, как, например, вебприложения и нативные программы. Вместе с этим, реализации протокола
тоже различные для различных типов приложений. Очевидно, что и в
стандартах OpenID и OAuth тоже даются классификации приложений [1].
Для исследования работы перенаправлений они неудобны тем, что не
учитывают используемый транспорт, то есть, то, какие именно типы
перенаправлений используются. Поэтому далее мы определим 4 различных
сценария работы SSO-протокола, основываясь на том, через какой транспорт
передаются сообщения.
19
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-запросов на сервер.
1.5.3 Модель Контроллер
Некоторые браузерные приложения используют iframe-контроллер для
получения учетных данных. В отличие от фрейма-прокси, который сразу
загружается с токеном в URL или внутри своей страницы, контроллер
получает учетные данные через XHR-запрос на домен провайдера. Такой
20
фрейм не должен перезагружаться, поскольку предназначен для выполнения
различных API-запросов и не только для аутентификациии или авторизации.
1.5.4 Нативная модель
В последней группе находятся различные типы установленных
приложений: нативные и мобильные. Такие приложения, в отличие от трех
предыдущих сценариев, выполняются вне браузера, и поэтому используют
для поддержки SSO-протокола либо встроенный, либо внешний браузер.
21
2 Атаки на некоторые SSO-сервисы и клиенты
2.1 Стандартная модель
Приложения и сервисы, реализующие логин по стандартной модели
оказались наиболее стойкими, поскольку они не используют никаких
дополнительных технологий или механизмов передачи данных, кроме HTTPперенаправлений. В некоторых случаях, однако, уязвимой реализации
перенаправлений вполне достаточно, чтобы атакующий смог получить
доступ к данным жертвы через украденные учетные данные. Такая проблема
актуальна, например, для implicit grant flow из OAuth 2, где известно, что
наличие Open redirector'а на сайте клиента может быть достаточно для кражи
токена из URL Fragment'а. При этом, с другой стороны, конечная точка
OAuth-провайдера тоже является Open redirector'ом, как было показано ранее.
Далее был исследован случай, когда клиент OAuth-провайдера тоже
содержит SSO-сервис на своем домене, так что его конечная точка SSO
реализует Open redirector, через который можно украсть URL Fragment с
учетными данными, выпущенными OAuth-провайдером:
Рисунок 3. Атака на SSO-сервисы, одновременно являющиеся SSO-клиентами
Из рассмотренных провайдеров потенциально уязвимым к такой атаке
являются Facebook и Microsoft Live Connect из-за недостаточно строгой
проверки redirect_uri. После этого возможность атаки проверялась на первых
50 сайтах из Alexa Top 500 Global Sites.
22
Из 50 сайтов 14 оказались клиентами Facebook OAuth 2, 7 из которых
одновременно предоставляли собственный SSO-сервис и 2 из них оказались
уязвимы к атаке кражи токена. Кроме рассмотренного случая с URL Fragment
также возможны атаки с кражей URL query.
2.2 Прокси-модель
Прокси-фреймы задействуют множество различных способов передачи
учетных данных клиентам помимо HTTP-перенаправлений. Одним из таких
способов является Fragment, поддерживаемый прокси-скриптами Facebook
OAuth 2 и Google OAuth 2. При передаче через этот транспорт прокси создает
внутри своего окна специальный фрейм с URL, принадлежащим OAuthклиенту. При этом, данные находятся в URL Fragment этого фрейма, который
клиент успешно считывает, поскольку его окно и созданный фрейм
находятся на одном домене. Поскольку URL для открытия передается
прокси-скрипту через параметр, а также поскольку фрейм может направить
внешнее окно (то есть, прокси) по новому адресу, этот транспорт можно
рассмотреть как особый вариант Open redirector'а в SSO-провайдере. Для
исследования здесь интересны возможные ошибки при конструировании
URL и при направлении фрейма по этому адресу:
Рисунок 4. Атака на транспорт Fragment в прокси-фрейме
23
Среди рассмотренных SSO-сервисов два из них используют проксифреймы для передачи данных: Facebook OAuth 2 и Google OAuth 2, в каждом
из них была найдена уязвимость, связанная с обработкой URL в транспорте
Fragment. Прокси-фрейм в Facebook позволял поместить токен из Fragment в
URL query, где такой токен становится уязвим к утечкам через Referrer и
краже с помощью main-in-the-middle, поскольку теперь будет передаваться
по сети вместе с URL, в отличие от Fragment-части. Прокси в Google OAuth 2
оказался уязвим к XSS благодаря слабой проверке параметра, задающего
URL для загрузки [37].
2.3 Модель Контроллер
В случае Контроллера не происходит открытия новых окон или
перенаправлений, но фрейм-контроллер отвечает за выполнение APIзапросов на сервер через XHR от имени клиента, который запрашивает вызов
какого-либо API-метода. При таком варианте возможно, что клиент может
повлиять на URL и направить Контроллер к конечной точке SSO вместо
загрузки необходимых данных:
24
Рисунок 5. Атака на XHR-обработчик Canvas-контроллера
Далее в работе была исследована платформа Facebook для Canvas приложений. Фрейм-контроллер этой платформы позволял клиенту задать
параметры для API-метода таким образом, конечная точка XHR для APIзапросов выполняла запрос на OAuth-авторизацию и возвращая HTTP-ответ с
кодом 302. Таким образом, удалось эксплуатировать XHR-обработчик,
который получал на вход результаты перенаправленного запроса вместо
оригинального. Поскольку возможность прозрачных перенаправлений при
XHR-вызовах браузером ограничена только исходным доменом, необходимо
было разместить нагрузку для эксплуатации XHR-обработчика на домене
facebook.com. В результате Canvas-платформа Facebook оказалась уязвимой к
XSS [38].
2.4 Нативная модель
Поскольку установленные приложения используют либо встроенный
или внешний браузер для поддержки SSO-логина, то одним из направлений
25
для атак является манипуляция состояниями используемого браузера и
обход политик или ограничений с помощью SSO-перенаправлений. Для
исследования был выбран браузер Google Chrome в качестве приложения для
атаки. Chrome позволяет выполнять синхронизацию данных после того, как
пользователь залогинится в свой аккаунт. Вход в аккаунт использует OAuth
2, реализован через веб-форму логина и защищен помощью изоляции сайтов
и особой политики для рендерера, выполняющего вход.
В ходе работы удалось выполнить успешную атаку на браузер, которая
состояла из трех шагов. Сначала для обхода CSRF-защиты в веб-форме входа
была использована XSS из 2.2. Далее в реализации ограничивающей
политики для signin-рендерера было найдено несколько уязвимостей [37],
связанных
с
неправильной
обработкой
OAuth-перенаправлений
и
позволяющих успешно завершить веб-логин и начать синхронизацию с
учетной записью атакующего без подтверждения:
Рисунок 6. Атака на изоляцию сайтов и политику доверенного рендерера
На этом шаге у атакующего уже был полный доступ к аккаунту
пользователя в Chrome. Последняя уязвимость позволяла выполнить код на
машине пользователя с его полными правами через установку NPAPIплагина.
26
Заключение
В работе была исследована безопасность современных технологий
единого входа, для этого были рассмотрены основные механизмы обмена
данными, задействованные семействами протоколов OAuth и OpenID. Работа
таких механизмов - различных типов перенаправлений HTTP - была
проанализирована в SSO-сервисах некоторых крупных провайдеров, после
чего показано, какие особенности и слабости есть у протоколов единого
входа. Для исследования потенциальных проблем и возможностей для их
эксплуатации предложена удобная классификация для различных вариантов
работы SSO-логина. Затем для каждого сценария работы SSO-протокола
найдена и показана во второй главе атака на приложение или сервис,
использующая исследованные слабые места протоколов единого входа.
В результате всей работы был исследован не изученный ранее вектор
для атак с использованием механизмов перенаправлений SSO, а также
выяснено и показано, что недостатки в защищенности SSO-протоколов
крупнейших сервис-провайдеров действительно существуют, кроме этого
информация о самих уязвимостях и рекомендации к устранению были
сообщены SSO-провайдерам. Обнаруженные в ходе работы уязвимости к
этому моменту исправлены разработчиками.
27
Список литературы
1. RFC
6749.
The
OAuth
2.0
Authorization
Framework.
URL:
http://tools.ietf.org/html/rfc6749 (Дата обращения: 05.02.2013)
2. OpenID
Authentication
2.0
–
Final,
2007.
URL:
http://openid.net/specs/openid-authentication-2_0.html (Дата обращения:
05.02.2013)
3. Chromium Code Reviews. Issue 7457007: Adding preliminary OAuth signin support (Closed). URL: https://codereview.chromium.org/7457007 (Дата
обращения: 05.02.2013)
4. Google
Developers.
Using
OAuth
2.0
for
Devices.
https://developers.google.com/accounts/docs/OAuth2ForDevices
URL:
(Дата
обращения: 05.02.2013)
5. SAP Help Portal. OAuth 2.0 - User Authentication and Single Sign-On.
URL:
http://help.sap.com/saphelp_nw74/helpdata/en/50/f9e740566b444fa72a2a01
9cc84888/content.htm?frameset=/en/f5/336b813bb340a990ee848364bb2464
/frameset.htm (Дата обращения: 05.02.2013)
6. A. Labunets. Pwning Facebook's OAuth 2.0 through URL hash tricks. URL:
http://isciurus.blogspot.ru/2012/09/pwning-facebook-authorizationthrough.html (Дата обращения: 05.02.2013)
7. K. Bhargavan, C. Bansal. Facebook JavaScript SDK Authorization
Vulnerabilities,
2012.
http://prosecco.gforge.inria.fr/CVE/Facebook_JS_2012.html
URL:
(Дата
обращения: 05.02.2013)
8. R. Wang, S. Chen, and X. Wang, "Signing Me onto Your Accounts through
Facebook and Google: a Traffic-Guided Security Study of Commercially
28
Deployed Single-Sign-On Web Services", in IEEE Symposium on Security
and Privacy, 2011.
9. S. Sun and K. Beznosov, "The Devil is in the (Implementation) Details: An
Empirical Analysis of OAuth SSO Systems", in Proceedings of ACM
Conference on Computer and Communications Security, 2012
10.E. Homakov and A. Labunets, "How we hacked Facebook with OAuth2 and
Chrome
bugs".
URL:
http://homakov.blogspot.ru/2013/02/hacking-
facebook-with-oauth2-and-chrome.html (Дата обращения: 05.02.2013)
11.N. Goldshlager, "How I Hacked Any Facebook Account...Again!". URL:
http://www.breaksec.com/?p=5753 (Дата обращения: 05.02.2013)
12.N.
Goldshlager.
The
Unfix
Bug
in
Facebook
OAuth.
URL:
http://www.breaksec.com/?p=6039 (Дата обращения: 05.02.2013)
13.N. Goldshlager. How I Hacked Facebook OAuth To Get Full Permission On
Any Facebook Account (Without App “Allow” Interaction). URL:
http://www.breaksec.com/?p=5734 (Дата обращения: 05.02.2013)
14. A. Labunets, "OAuth 2.0 and the Road to XSS: attacking Facebook
Platform", Hack In The Box, Amsterdam, 2013
15. A. Labunets, "A story of $9500 bug in Facebook OAuth 2.0", URL:
http://isciurus.blogspot.ru/2013/04/a-story-of-9500-bug-in-facebook-oauth20.html (Дата обращения: 05.02.2013)
16.J. Bradley. Latest Facebook security vulnerability is a learning opportunity
for other developers. URL: http://www.thread-safe.com/2013/10/latestfacebook-security-vulnerability.html (Дата обращения: 05.02.2013)
17.E. Sachs, "Vulnerability report: Data confusion", OpenID Foundation, URL:
http://openid.net/2012/03/14/vulnerability-report-data-confusion/
(Дата
обращения: 05.02.2013)
29
18.OAuth Security Advisory: 2009.1, URL: http://oauth.net/advisories/2009-1/
(Дата обращения: 05.02.2013)
19.M. Uruena and . Busquiel, "Analysis of a Privacy Vulnerability in the
OpenID Authentication Protocol," IEEE Multimedia Communications,
Services and Security, 2010
20.S. Chari, C. Jutla, and A. Roy. "Universally composable security analysis of
OAuth v2.0.", Cryptology ePrint Archive, Report 2011/526, 2011
21.M. Miculan and C. Urban. Formal analysis of Facebook Connect Single
Sign-On authentication protocol. In SofSem 2011, Proceedings of Student
Research Forum, pages 99–116, 2011.
22.S. Pai, Y. Sharma, S. Kumar, R. M Pai and S. Singh, "Formal Verification of
OAuth 2.0 using Alloy Framework", in International Conference on
Communication Systems and Network Technologies, 2011
23.Q. Slack and R. Frostig, "OAuth 2.0 implicit grant flow analysis using
Murphi.".
URL:
http://www.stanford.edu/class/cs259/WWW11/
(Дата
обращения: 05.02.2013)
24.RFC 6819. OAuth 2.0 Threat Model and Security Considerations. URL:
http://tools.ietf.org/html/rfc6819 (Дата обращения: 05.02.2013)
25.Wikipedia.
OAuth.
URL:
http://en.wikipedia.org/wiki/OAuth
(Дата
обращения: 05.02.2013)
26.E.
Hammer.
OAuth
2.0
and
the
Road
to
Hell.
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
URL:
(Дата
обращения: 05.02.2013)
27.RFC 6819. OAuth 2.0 Threat Model and Security Considerations. URL:
http://tools.ietf.org/html/rfc6819 (Дата обращения: 05.02.2013)
30
28.OpenID
Realm
Spoofing
-
OpenID_Phishing_Brainstorm.
URL:
http://wiki.openid.net/w/page/12995216/OpenID_Phishing_Brainstorm
(Дата обращения: 05.02.2013)
29.D. Akhawe, A. Barth, P. E. Lam, J. Mitchell, D. Song, "Towards a Formal
Foundation of Web Security," csf, pp.290-304, 2010 23rd IEEE Computer
Security Foundations Symposium, 2010
30.San-Tsai Sun, Eric Pospisil, Eric Pospisil, Ildar Muslukhov, Nuray Dindar,
Kirstie Hawkey, Konstantin Beznosov. "What Makes Users Refuse Web
Single Sign-On? An Empirical Investigation of OpenID," Symposium On
Usable Privacy and Security, 2011
31.ActionScript
3.0
Reference
for
the
Adobe
Flash
Platform,
"LocalConnection".
URL:
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ne
t/LocalConnection.html (Дата обращения: 05.02.2013)
32.Shindig.
Apache
Software
Foundation
Subversion
Server
URL:
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/fea
tures/rpc/ (Дата обращения: 05.02.2013)
33.Open redirect. Open Web Application Security Project (OWASP). URL:
https://www.owasp.org/index.php/Open_redirect
(Дата
обращения:
05.02.2013)
34.CWE-601: URL Redirection to Untrusted Site ('Open Redirect'). Common
Weakness Enumeration. URL: http://cwe.mitre.org/data/definitions/601.html
(Дата обращения: 05.02.2013)
35.Bellamy-McIntyre, J., Luterroth, C., Weber, G. OpenID and the Enterprise:
A Model-Based Analysis of Single Sign-On Authentication. Enterprise
Distributed Object Computing Conference (EDOC). 2011 15th IEEE
International. pp.129-138, Aug. 29 2011-Sept. 2 2011
31
36. E. Homakov. The Achilles Heel of OAuth or Why Facebook Adds #_=_.
URL:
http://homakov.blogspot.ru/2013/03/redirecturi-is-achilles-heel-of-
oauth.html (Дата обращения: 05.02.2013)
37.Chromium sync session fixation + code execution. Chromium - Google
Project
Hosting.
https://code.google.com/p/chromium/issues/detail?id=252010
URL:
(Дата
обращения: 05.02.2013)
38.One of our favorite OAuth bugs to date - Facebook Bug Bounty. URL:
https://www.facebook.com/BugBounty/posts/627709933909903
(Дата
обращения: 05.02.2013)
32