SAML и федерация

SAML (язык разметки утверждений безопасности) — стандарт на основе XML для обмена данными об аутентификации и авторизации, широко используемый в корпоративном SSO.

• Он позволяет корпоративному поставщику удостоверений подтверждать личность пользователя для множества приложений.
• SAML 2.0 появился раньше OIDC, но по-прежнему широко используется в идентификации B2B и сотрудников.

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

В федерации SAML участвуют две основные стороны.

• Поставщик удостоверений (IdP) аутентифицирует пользователя и выпускает утверждения (Okta, Entra ID, Ping).
• Поставщик услуг (SP) — приложение, которое доверяет IdP и предоставляет доступ.

Доверие устанавливается заранее, вне протокола, путем обмена метаданными, включая сертификаты подписи и URL конечных точек.

Основной объект — это утверждение, XML-документ, сообщающий, что IdP аутентифицировал субъекта.

• Субъект идентифицирует пользователя (NameID).
• Условия определяют период действия и предполагаемую аудиторию.
• AuthnStatement фиксирует, как и когда проходила аутентификация.
• AttributeStatement содержит роли, адрес электронной почты и утверждения о группах.

Наиболее распространенный вариант — это SSO, инициированный SP.

• Пользователь обращается к SP, который создает AuthnRequest и перенаправляет его на IdP.
• IdP аутентифицирует пользователя и отправляет подписанный Response методом POST обратно в службу потребления утверждений SP (ACS).
• SP проверяет утверждение и создает локальный сеанс.

Безопасность SAML основана на цифровых подписях XML. IdP подписывает утверждение и/или ответ своим закрытым ключом, а SP проверяет подпись с помощью доверенного сертификата.

• Подписывайте само утверждение, а не только внешний ответ.
• Проверяйте подпись по закрепленному сертификату IdP из метаданных, а не по сертификату, встроенному в сообщение.

Большинство атак на SAML направлено на логику проверки подписи.

Оборачивание XML-подписи — это класс атак на подпись в SAML. Атакующий сохраняет действительный подписанный элемент, но добавляет второе поддельное утверждение, которое фактически обрабатывает логика приложения.

• Подпись по-прежнему проходит проверку для исходного фрагмента.
• Но бизнес-логика обрабатывает внедренное неподписанное утверждение.

Меры защиты: используйте усиленную библиотеку SAML, проверяйте, что обработке подвергается именно подписанный элемент, и отклоняйте документы с несколькими или неоднозначными утверждениями.

Утверждение должно быть связано с предназначенным для него SP. SAML предоставляет для этого явные ограничения.

• AudienceRestriction указывает ID сущности SP, для которого действительно утверждение.
• Получатель в SubjectConfirmation должен совпадать с URL ACS.

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

Утверждения — это краткосрочные учетные данные, которые можно использовать один раз. SP должны обеспечивать это ограничение.

• Учитывайте NotBefore и NotOnOrAfter, допуская лишь небольшое расхождение показаний часов.
• Отслеживайте ID утверждения и отклоняйте любое повторное использование в течение периода действия.
• Требуйте TLS для конечной точки ACS.

Без отслеживания повторного использования перехваченное утверждение можно повторно отправить до истечения срока его действия.

Федерация масштабирует SSO между организациями, иногда через узлы или брокеры, которые преобразуют протоколы.

• Каждая связь доверия может стать слабым местом: скомпрометированный поставщик удостоверений позволяет выдавать себя за любого пользователя.
• Брокеры удостоверений могут связывать SAML и OIDC, поэтому необходимо тщательно сопоставлять утверждения.

Применяйте принцип минимальных привилегий при сопоставлении атрибутов и отслеживайте появление неожиданных новых регистраций поставщиков услуг.

Распространённые сценарии отказа SAML, которые стоит проверять:

• Подпись не проверяется или подписан ответ, но не утверждение.
• Система уязвима к обёртыванию XML-подписи.
• Отсутствуют проверки аудитории и получателя.
• Нет защиты от повторного воспроизведения или установлены чрезмерно длительные периоды действия.
• На стороне поставщика услуг выполняется разбор XML с поддержкой внешних сущностей (XXE).
• Система доверяет сертификату, встроенному в сообщение, вместо закреплённых метаданных.

Оба протокола обеспечивают SSO, но отличаются архитектурой.

• SAML использует XML и привязки браузера через POST/перенаправление, широко применяется в корпоративной среде и имеет зрелые инструменты.
• OIDC использует JSON/JWT, удобен для REST и лучше подходит для мобильных приложений и одностраничных приложений.

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

Выберите наиболее эффективную защиту от описанной атаки.

Основные выводы:

• SAML — это корпоративный SSO на основе XML между поставщиком удостоверений и поставщиком услуг с использованием подписанных утверждений.
• Безопасность зависит от правильной проверки XML-подписи с использованием закреплённого сертификата.
• Защищайтесь от обёртывания XML-подписи, повторного воспроизведения и XXE.
• Всегда применяйте ограничения для аудитории и получателя, а также проверяйте периоды действия.
• Федерация масштабирует доверие, но увеличивает радиус поражения при компрометации поставщика удостоверений.