Перед тобой практическое руководство по аудиту безопасности веб-приложений с поддержкой SAML SSO. Single Sign-On — это технология, которая позволяет логиниться в веб-приложение через сторонний сайт (провайдер). А SAML — это популярный XML-протокол для реализации SSO. Мы подробно расскажем, что такое SAML SSO, как он работает. Опишем, каким образом настроить свое приложение на работу с SAML IdP. И наконец, расскажем самое важное — какие инструменты нужно использовать для пентестов, на наличие каких уязвимостей нужно проверять приложение. XXE, атаки через преобразования, XPath-инъекции, ошибки при проверке подписи, атаки XSW, атаки на зашифрованные assertions и многое другое. Велком!

 

Что такое SAML SSO и зачем он нужен?

Single Sign-On (SSO) — это технология, которая позволяет залогиниться в веб-приложении через сторонний сайт-провайдер. К плюсам использования SSO можно отнести следующее:

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

К минусам можно отнести следующее:

  • Атакующему нужно узнать только один пароль, чтобы получить доступ сразу к нескольким приложениям от имени пользователя.
  • Необходимо доверять SSO-провайдеру, который представляет собой «черный ящик». Как правило, владелец приложения ничего не знает о безопасности SSO-провайдера: каким образом хранится аутентификационная информация, кто имеет к ней доступ, какие действия предпринимает SSO-провайдер для обеспечения безопасности.
  • SSO-провайдер — это точка отказа. Если по каким-то причинам он недоступен, это приведет к неработоспособности приложения.
  • Код на стороне приложения, отвечающий за SSO, — это дополнительный источник уязвимостей.

Security Assertion Markup Language (SAML) — это открытый стандарт, который описывает фреймворк, позволяющий обеим сторонам (приложению и провайдеру) обмениваться аутентификационной и авторизационной информацией. Аутентификационная и авторизационная информация представляется в виде набора утверждений (assertions), которые подписаны провайдером (и в некоторых случаях зашифрованы).

На момент написания статьи последняя версия стандарта — SAML 2.0.

По стандарту SAML клиент (веб-приложение) и провайдер аутентификации обмениваются аутентификационными утверждениями (assertions) через XML. А это означает, что SAML основан на следующих стандартах w3c, относящихся к XML:

  • Extensive Markup Language — стандарт, касающийся языка XML;
  • XML Schema — стандарт, касающийся XML-схем;
  • XML Signature — cтандарт, относящийся к обработке цифровых подписей в XML;
  • XML Encryption — cтандарт, относящийся к шифрованию данных в XML.

У SAML есть множество сценариев применения:

  • Web SSO;
  • Attribute based authorization;
  • Identity Federation;
  • WS-Security.

Web SSO (или SAML SSO в нашей терминологии) — это наиболее распространенный юзкейс для SAML, поэтому самый интересный с точки зрения безопасности. В нем мы и будем сегодня разбираться.

В аутентификации через SAML SSO участвуют три стороны:

  • провайдер аутентификации (SAML identity Provider или SAML IdP);
  • веб-приложение (SAML Service Provider или SAML SP);
  • браузер пользователя (User Agent).

User Agent аутентифицируется на стороне SAML IdP, а затем получает доступ к веб-приложению. Веб-приложение доверяет провайдеру и получает от него аутентификационную информацию. Стороны SAML SSO и их взаимоотношения представлены на рис. 1.

Рис. 1. Стороны SAML SSO и их взаимоотношения
Рис. 1. Стороны SAML SSO и их взаимоотношения

В качестве IdP провайдера может выступать один из онлайн-сервисов, таких как OneLogin, Ping Identity, Okta и другие. Или ты можешь развернуть свой IdP, используя софт — Shibboleth или OpenAM. Рассмотрим по шагам, каким образом приложение аутентифицируется на стороне провайдера и затем получает доступ к приложению.

Существует два альтернативных flow для SAML SSO: SP-initiated flow и IdP-initiated flow. Различие заключается в том, к кому обращается User Agent в начале процесса — к приложению или к провайдеру. Мы рассмотрим SP-initiated flow, который представлен на рис. 2.

На первом шаге User Agent обращается к приложению. Так как пользователь не был аутентифицирован, приложение перенаправляет браузер на страницу аутентификации провайдера — IdP Login URL. Этот URL приложение берет из конфигурации SAML. В момент редиректа приложение добавляет параметр SAMLRequest в строку запроса (query string).

Браузер делает запрос к IdP Login URL c параметром SAMLRequest. IdP аутентифицирует пользователя и делает редирект браузера обратно в приложение (на Assertion Consumer URL или ACS URL) с параметром SAML Response в строке запроса, который содержит закодированное сообщение Response. В сообщении Response содержатся утверждения (assertions), которые подписаны провайдером (и, возможно, зашифрованы). Провайдер использует значение ACS URL из конфигурации SAML для этого приложения.

Браузер запрашивает ACS URL и передает SAML Response в качестве параметра запроса. Приложение проверяет подпись сообщения Response и подпись каждого assertion (и, возможно, расшифровывает assertion). Для этого приложение использует сертификат провайдера, который хранится в конфигурации SAML.

Далее приложение на основе данных assertion создает сессию для пользователя, делает редирект браузера на страницу /app/profile и устанавливает cookie с идентификатором сессии пользователя.

Рис. 2. SAML SP-initiated flow
Рис. 2. SAML SP-initiated flow
 

Настраиваем SAML SSO в приложении

После того как мы разобрались с теорией, приступим к настройке SAML SSO для тестируемого приложения. У нас есть развернутое приложение, теперь нам нужен SAML IdP (провайдер). Я предпочитаю OneLogin, он популярен, и многие приложения его поддерживают. Еще OneLogin предоставляет полезные утилиты, которые тебе пригодятся при тестировании безопасности. Утилиты находятся здесь.

Регистрируем бесплатный девелоперский аккаунт. Идем в APPS → Company Apps, затем нажимаем кнопку Add Apps. В строке поиска необходимо набрать SAML Test Connector, как показано на рис. 3. Далее выбираем SAML Test Connector (IdP w/attr).

Рис. 3. Создание тестового коннектора
Рис. 3. Создание тестового коннектора

Задаем имя для коннектора и нажимаем кнопку Save.

На стороне нашего приложения идем в настройки SAML IdP (рис. 4). Нам нужно скопировать значения полей Issuer, ACS URL, Logout URL. Эти три параметра нам генерирует приложение, и они используются для настройки коннектора на стороне IdP.

Рис. 4. Настройки SAML IdP приложения
Рис. 4. Настройки SAML IdP приложения

Параметры, которые сгенерировало приложение, необходимо перенести в настройки коннектора, как показано на рис. 5. На этом все, настройка коннектора завершена!

Рис. 5. Настройка коннектора
Рис. 5. Настройка коннектора

Переходим на вкладку SSO. Копируем значения X.509 certificate, Issuer URL, SAML Endpoint и SLO Endpoint из настроек коннектора в настройки нашего приложения (рис. 6).

Рис. 6. Параметры SSO
Рис. 6. Параметры SSO

Далее необходимо создать пользователя в IdP. Для этого идем в Users → All Users, как показано на рис. 7. Нажимаем кнопку New User.

Рис. 7. Создание пользователя на стороне IdP
Рис. 7. Создание пользователя на стороне IdP

Создаем нового пользователя, указываем email и пароль. Переходим на вкладку Applications и выбираем сконфигурированный нами коннектор (рис. 8).

Рис. 8. Привязка пользователя к коннектору
Рис. 8. Привязка пользователя к коннектору

В нашем приложении создаем пользователя с таким же email, так как связка пользователей между IdP и нашим приложением осуществляется по email. На этом настройка SAML SSO завершена.

Когда мы пытаемся залогиниться в наше приложение, оно редиректит нас к IdP на страницу логина — SAML 2.0 endpoint (см. конфигурацию коннектора в OneLogin). После успешного логина пользователя на стороне IdP происходит редирект в наше приложение на ACS URL. В параметре SAML Response передается закодированное в Base64 сообщение Response (рис. 9).

Рис. 9. Передача SAML Response в приложение
Рис. 9. Передача SAML Response в приложение

Мы можем декодировать Response. Для этого используем эту утилиту (рис. 10):

Рис. 10. URL decoding
Рис. 10. URL decoding

А затем, используя эту утилиту, мы получим XML Response, которым подписан IdP (рис. 11).

Рис. 11. Base64 decoding
Рис. 11. Base64 decoding

Если SAML Response был сжат на стороне IdP, то для декодирования тебе нужно использовать Base64 Decode + Inflate вместо Base64 Decode.

Все, на этом процесс настройки и отладки SAML SSO завершен. Переходим к самому интересному — багам!

 

Арсенал для тестирования SAML SSO

На данном этапе у тебя есть тестируемое приложение с работоспособным SAML SSO. Разберемся, какие инструменты использовать для тестирования безопасности.

Продолжение статьи доступно только подписчикам

Вариант 1. Оформи подписку на «Хакер», чтобы читать все статьи на сайте

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

Вариант 2. Купи одну статью

Заинтересовала статья, но нет возможности оплатить подписку? Тогда этот вариант для тебя! Обрати внимание: этот способ покупки доступен только для статей, опубликованных более двух месяцев назад.


Комментарии

Подпишитесь на ][, чтобы участвовать в обсуждении

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

Check Also

ИБ-специалист борется с нелегальной торговлей в даркнете, обнаруживая реальные IP-адреса сайтов

После закрытия таких крупных торговых площадок, как AlphaBay и Hansa, многие злоумышленник…