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

1.5.3 Модель Контроллер

Некоторые браузерные приложения используют iframe-контроллер для получения учетных данных. В отличие от фрейма-прокси, который сразу загружается с токеном в URL или внутри своей страницы, контроллер получает учетные данные через XHR-запрос на домен провайдера. Такой фрейм не должен перезагружаться, поскольку предназначен для выполнения различных API-запросов и не только для аутентификациии или авторизации.

1.5.4 Нативная модель

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

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.

Из 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 в прокси-фрейме

Среди рассмотренных 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 вместо загрузки необходимых данных:

Рисунок 5. Атака на XHR-обработчик Canvas-контроллера

Далее в работе была исследована платформа Facebook для Canvas - приложений. Фрейм-контроллер этой платформы позволял клиенту задать параметры для API-метода таким образом, конечная точка XHR для API-запросов выполняла запрос на OAuth-авторизацию и возвращая HTTP-ответ с кодом 302. Таким образом, удалось эксплуатировать XHR-обработчик, который получал на вход результаты перенаправленного запроса вместо оригинального. Поскольку возможность прозрачных перенаправлений при XHR-вызовах браузером ограничена только исходным доменом, необходимо было разместить нагрузку для эксплуатации XHR-обработчика на домене . В результате Canvas-платформа Facebook оказалась уязвимой к XSS [38].

2.4 Нативная модель

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

В ходе работы удалось выполнить успешную атаку на браузер, которая состояла из трех шагов. Сначала для обхода CSRF-защиты в веб-форме входа была использована XSS из 2.2. Далее в реализации ограничивающей политики для signin-рендерера было найдено несколько уязвимостей [37], связанных с неправильной обработкой OAuth-перенаправлений и позволяющих успешно завершить веб-логин и начать синхронизацию с учетной записью атакующего без подтверждения:

Рисунок 6. Атака на изоляцию сайтов и политику доверенного рендерера

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

Заключение

В работе была исследована безопасность современных технологий единого входа, для этого были рассмотрены основные механизмы обмена данными, задействованные семействами протоколов OAuth и OpenID. Работа таких механизмов - различных типов перенаправлений HTTP - была проанализирована в SSO-сервисах некоторых крупных  провайдеров, после чего показано, какие особенности и слабости есть у протоколов единого входа. Для исследования потенциальных проблем и возможностей для их эксплуатации предложена удобная классификация для различных вариантов работы SSO-логина. Затем для каждого сценария работы SSO-протокола найдена и показана во второй главе атака на приложение или сервис, использующая исследованные слабые места протоколов единого входа.

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

Список литературы

RFC 6749. The OAuth 2.0 Authorization Framework. URL: http://tools. ietf. org/html/rfc6749 (Дата обращения: 05.02.2013) OpenID Authentication 2.0 – Final, 2007. URL: http:///specs/openid-authentication-2_0.html (Дата обращения: 05.02.2013) Chromium Code Reviews. Issue 7457007: Adding preliminary OAuth sign-in support (Closed). URL: https://codereview. chromium. org/7457007 (Дата обращения: 05.02.2013) Google Developers. Using OAuth 2.0 for Devices. URL: https://developers. /accounts/docs/OAuth2ForDevices (Дата обращения: 05.02.2013) SAP Help Portal. OAuth 2.0 - User Authentication and Single Sign-On. URL: http://help. /saphelp_nw74/helpdata/en/50/f9e740566b444fa72a2a019cc84888/content. htm? frameset=/en/f5/336b813bb340a990ee848364bb2464/frameset. htm (Дата обращения: 05.02.2013) A. Labunets. Pwning Facebook's OAuth 2.0 through URL hash tricks. URL: http://isciurus. blogspot. ru/2012/09/pwning-facebook-authorization-through. html (Дата обращения: 05.02.2013) K. Bhargavan, C. Bansal. Facebook JavaScript SDK Authorization Vulnerabilities, 2012. URL: http://prosecco. gforge. inria. fr/CVE/Facebook_JS_2012.html (Дата обращения: 05.02.2013) R. Wang, S. Chen, and X. Wang, "Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services", in IEEE Symposium on Security and Privacy, 2011. n 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 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) N. Goldshlager, "How I Hacked Any Facebook Account...Again!". URL: http://www. /?p=5753 (Дата обращения: 05.02.2013) N. Goldshlager. The Unfix Bug in Facebook OAuth. URL: http://www. /?p=6039 (Дата обращения: 05.02.2013) N. Goldshlager. How I Hacked Facebook OAuth To Get Full Permission On Any Facebook Account (Without App “Allow” Interaction). URL: http://www. /?p=5734 (Дата обращения: 05.02.2013) A. Labunets, "OAuth 2.0 and the Road to XSS: attacking Facebook Platform", Hack In The Box, Amsterdam, 2013 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-oauth-20.html (Дата обращения: 05.02.2013) J. Bradley. Latest Facebook security vulnerability is a learning opportunity for other developers. URL: http://www. /2013/10/latest-facebook-security-vulnerability. html (Дата обращения: 05.02.2013) E. Sachs, "Vulnerability report: Data confusion", OpenID Foundation, URL: http:///2012/03/14/vulnerability-report-data-confusion/ (Дата обращения: 05.02.2013) OAuth Security Advisory: 2009.1, URL: http:///advisories/2009-1/ (Дата обращения: 05.02.2013) M. Uruena and. Busquiel, "Analysis of a Privacy Vulnerability in the OpenID Authentication Protocol," IEEE Multimedia Communications, Services and Security, 2010 S. Chari, C. Jutla, and A. Roy. "Universally composable security analysis of OAuth v2.0.", Cryptology ePrint Archive, Report 2011/526, 2011 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. 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 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) RFC 6819. OAuth 2.0 Threat Model and Security Considerations. URL: http://tools. ietf. org/html/rfc6819 (Дата обращения: 05.02.2013) Wikipedia. OAuth. URL: http://en. wikipedia. org/wiki/OAuth (Дата обращения: 05.02.2013) E. Hammer. OAuth 2.0 and the Road to Hell. URL: http:///2012/07/oauth-2-0-and-the-road-to-hell/ (Дата обращения: 05.02.2013) RFC 6819. OAuth 2.0 Threat Model and Security Considerations. URL: http://tools. ietf. org/html/rfc6819 (Дата обращения: 05.02.2013) OpenID Realm Spoofing - OpenID_Phishing_Brainstorm. URL: http://wiki. /w/page/12995216/OpenID_Phishing_Brainstorm (Дата обращения: 05.02.2013) 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 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 ActionScript 3.0 Reference for the Adobe Flash Platform, "LocalConnection". URL: http://help. /en_US/FlashPlatform/reference/actionscript/3/flash/net/LocalConnection. html (Дата обращения: 05.02.2013) Shindig. Apache Software Foundation Subversion Server URL: http://svn. apache. org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/ (Дата обращения: 05.02.2013) Open redirect. Open Web Application Security Project (OWASP). URL: https://www. owasp. org/index. php/Open_redirect (Дата обращения: 05.02.2013) CWE-601: URL Redirection to Untrusted Site ('Open Redirect'). Common Weakness Enumeration. URL: http://cwe. mitre. org/data/definitions/601.html (Дата обращения: 05.02.2013) 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 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) Chromium sync session fixation + code execution. Chromium - Google Project Hosting. URL: https://code. /p/chromium/issues/detail? id=252010 (Дата обращения: 05.02.2013) One of our favorite OAuth bugs to date - Facebook Bug Bounty. URL: https://www. /BugBounty/posts/627709933909903 (Дата обращения: 05.02.2013)