Trail of Bits: SAML, «фрактал плохого дизайна», пора на OIDC

Блог компании Trail of Bits разбирает протокол единого входа SAML (Security Assertion Markup Language) и приходит к выводу, что его пора списывать в пользу более современного OpenID Connect (OIDC). SAML создали в 2002 году в комитете OASIS SSTC, слив в одну спецификацию сразу четыре конкурировавших XML-протокола: Security Services Markup Language (S2ML) от Netegrity, AuthXML от Securant, XML Trust Assertion Service Specification (X-TASS) от VeriSign и Information Technology Markup Language (ITML) от Jamcracker. Автор указывает, что дизайн «большим комитетом» с самого начала предрасполагал к раздутой, «кухонно-раковинной» спецификации.

Дальше протокол рос вместе с академической и коммерческой инфраструктурой SSO: в 2002 году в Йеле появился Central Authentication Service (CAS), в 2003-м, Shibboleth IdP консорциума Internet2 и ADFS от Microsoft, около 2007 года, simpleSAMLphp норвежской Uninett. На этой базе выросла целая индустрия провайдеров идентификации: Ping Identity (2002), OneLogin и Okta (обе, 2009), Duo Security (2010). Автор лично застал этот период: он работал над первым локальным SSO-продуктом Duo (Duo Access Gateway, 2015 год), построенным на simpleSAMLphp, и был свидетелем находки Келби Людвига (Kelby Ludwig), обхода через XML-комментарии, ставшего возможным из-за багов каноникализации, в 2018 году.

Автор выделяет пять фатальных для SAML изъянов дизайна. Первый, сама зависимость от XML: формат сложнее JSON и тянет за собой целый класс XML-специфичных уязвимостей (XXE, «billion laughs», раздувание сущностей, SSRF через загрузку DTD, инъекции через XPath/XQuery/XInclude/XSLT/CDATA), которые любая библиотека SAML обязана закрыть ещё до реализации собственно логики протокола. Второй, каноникализация (C14N): чтобы подпись сошлась, поставщик услуги (SP) и поставщик идентификации (IdP) должны получить из XML-документа побайтово одинаковое представление, а это в XML не гарантировано и порождает атаки на несовпадение парсеров («parser differential», «round-trip»). Именно такие баги каноникализации в 2018 году позволили Людвигу обойти проверку подписи через XML-комментарий. Третий изъян, «встроенные» (enveloped) подписи: элемент подписи вставлен прямо внутрь подписываемого блока Assertion, из-за чего получить каноничное побайтовое представление данных при их же модификации крайне сложно; для сравнения, в JWT подпись отделена от полезной нагрузки точкой. Четвёртый, «кухонно-раковинный» дизайн по принципу «а вдруг понадобится»: по оценке автора, около 99% реальных реализаций SAML используют один и тот же узкий поднабор спецификации, а типичная аутентификация задействует не больше 10% всего стандарта, остальное лишь наращивает поверхность для ошибок. Пятый, «окостенение» (ossification): в отличие от SAML, OIDC изначально привязан к HTTP и опирается на TLS транспортного уровня вместо собственной криптографии; OIDC в основном сценарии (authorization code) предполагает прямую связь между провайдером (OP) и потребителем (RP), что снимает нагрузку с самого токена, тогда как в SAML такая связь необязательна и почти не используется на практике; наконец, OIDC вырастал органически, из десятков спецификаций и RFC, публиковавшихся годами (сама OpenID Connect 1.0 вышла в 2014-м, набор JOSE, RFC 7515, 7519, в 2015-м, PKCE, RFC 7636, тоже в 2015-м), тогда как SAML был спроектирован «наперёд» одним крупным документом по модели, близкой к waterfall.

С 2012 года, после публикации статьи «On Breaking SAML: Be Whoever You Want to Be», исследования, которое автор называет «крёстным отцом» атак класса XML Signature Wrapping (XSW, до неё были более ранние работы 2005, 2008 и 2009 годов), этот класс атак продолжает всплывать в реализациях SAML. Автор приводит список профильных работ и находок вплоть до 2025 года: обход через квирки libxml2 в GitHub Enterprise, атака «Sign in as anyone» через различия парсеров, «SAML roulette» и «The Fragile Lock». Материал приводит две цитаты исследователя Томаса Птачека (Thomas Ptacek, годы цитат, 2023 и 2021): о том, что надёжность SAML держится на предположении о корректности проверки XML-подписей, которая на практике «прокляла» большинство реализаций (те просто оборачивают библиотеку libxmlsec, малочитаемую C-кодовую базу), и о практической рекомендации, при добавлении поддержки SAML отбрасывать любые сообщения, форма которых отличается от того, что генерируют Okta, OneLogin, Google или Shibboleth.

Ключевые факты

• SAML появился в 2002 году, когда комитет OASIS SSTC объединил в одной спецификации сразу четыре конкурировавших XML-протокола (S2ML, AuthXML, X-TASS, ITML), отсюда унаследованная избыточность.
• На SAML построена вся ранняя индустрия SSO, Ping Identity, OneLogin, Okta, а также первый шлюз Duo Security (2015 год); автор сам работал над этим продуктом.
• Автор называет пять фатальных изъянов дизайна: зависимость от сложного XML, ненадёжная каноникализация, встроенные (enveloped) подписи, избыточный «кухонно-раковинный» набор функций и общее «окостенение» протокола по сравнению с OIDC.
• С 2012 года и до работ 2025 года атаки класса XML Signature Wrapping (XSW) продолжают находить в реализациях SAML, несмотря на то, что этот класс уязвимостей известен уже больше десяти лет.
• По оценке автора, около 99% реализаций SAML используют один и тот же узкий поднабор спецификации, а типовая аутентификация задействует не более 10% всего стандарта, остальное предлагается заменить переходом на OpenID Connect (OIDC).

Почему это важно

SAML по-прежнему остаётся стандартом единого входа во множестве корпоративных IT-систем, и материал показывает, что его проблемы, не отдельные баги, а следствие архитектурных решений двадцатилетней давности: зависимости от XML, ненадёжной каноникализации и встроенных подписей. Пока эти решения не меняются, новые обходы аутентификации (последний пример, 2025 год) будут появляться регулярно, а не как исключение.

Кому это важно

Материал адресован инженерам по безопасности, разработчикам identity- и SSO-систем и IT-командам, которые поддерживают или планируют интеграции через SAML, то есть тем, кто выбирает протокол для новой аутентификации или отвечает за уже развёрнутые SP/IdP-связки на его основе.

Как это применить

Для новых интеграций автор советует смотреть в сторону OpenID Connect (OIDC) как более простой и лучше проверенной альтернативы. Там, где отказаться от SAML пока нельзя, предлагается сузить принимаемый формат: проверять не только штатные требования спецификации, но и то, что форма сообщения совпадает с тем, что реально генерируют Okta, OneLogin, Google или Shibboleth, это на практике отсекает большую часть нетипичных, потенциально вредоносных вариаций.

Можно ли доверять

Материал опубликован Trail of Bits, компанией, специализирующейся на security-аудитах, и опирается на конкретные датированные источники: исследовательскую статью 2012 года, RFC OpenID Connect и JOSE, а также именованные находки уязвимостей вплоть до 2025 года. Автор описывает личный опыт работы над SSO-продуктом Duo Access Gateway, а не только теорию. Две ключевые цитаты принадлежат названному по имени исследователю Томасу Птачеку; его должность или место работы в тексте не указаны.

Риски и подводные камни

Материал, это авторская позиция security-исследователя, а не нейтральный отчёт: аргументы в пользу отказа от SAML подобраны для конкретного вывода. Сохранённый текст обрывается на середине хронологии раздела про OIDC и не содержит финального вывода или заключения статьи, итоговые рекомендации автора по срокам и деталям перехода на OIDC по этому фрагменту не восстановить. Практический риск для тех, кто пока не может отказаться от SAML: библиотеки вроде libxmlsec редко проходят полный аудит, а класс атак XML Signature Wrapping продолжает давать новые обходы даже в свежих, казалось бы, проверенных реализациях.

«Что подкупает в SAML, то, что понять его в целом несложно, но построен он на фундаменте из песка, костной пыли и пепла: работает, если считать проверку XML-подписей надёжной. Но проверка XML-подписей, вещь глубоко проклятая, настолько сложная, что большинство реальных реализаций SAML просто оборачивают libxmlsec, жуткую C-кодовую базу, которую никто не читает.»

— Томас Птачек (Thomas Ptacek), 2023