SAML изнутри: подпись внутри письма
SAML позволяет вам входить почти во все рабочие приложения, а его подпись находится внутри XML-документа, который она подписывает.
SAML позволяет вам входить почти во все рабочие приложения, а его подпись находится внутри XML-документа, который она подписывает. Изнутри: процесс входа между приложением, браузером и поставщиком удостоверений, как выглядит утверждение, почему канонизация должна совпадать до каждого байта и почему один и тот же класс ошибок повторяется с 2012 по 2025 год. По мотивам статьи Trail of Bits «SAML: фрактал плохого дизайна» (312 баллов на Hacker News).
Читать письменное издание (на английском) ↗
Что освещается в этом видео
- SAML: вход, который подписывает сам себя изнутри
- 2002 год: четыре формата XML, один комитет, целая индустрия
- Процесс входа: приложение → поставщик удостоверений → обратно через ваш браузер
- Утверждение: подпись находится внутри того, что она подписывает
- Канонизация: совпадение до каждого байта, иначе никто не войдет
Переведенная стенограмма
Переведено с оригинального английского повествования. Доступные аудио и субтитры контролируются YouTube.
SAML: вход, который подписывает сам себя изнутри
0:00 SAML — это XML, который позволяет вам входить почти во все ваши рабочие приложения, и его подпись находится внутри документа, который он подписывает, как нотариус, прикрепляющий свою печать внутри запечатываемого им конверта. Спустя десять лет после того, как комитет написал его, исследователи протестировали четырнадцать фреймворков SAML. Одиннадцать из них не прошли проверку. И на этой неделе пост Trail of Bits, называющий его фракталом плохого дизайна, попал на главную страницу Hacker News. За три минуты: как работает процесс входа, где прячется подпись,
0:27 и почему решение, с которым все согласны, — это другой протокол. Это The Daily Diff, изнутри.
2002 год: четыре формата XML, один комитет, целая индустрия
0:34 Две тысячи второй год. Комитет по безопасности в Oasis объединяет четыре XML-формата от разных поставщиков в один. Университеты принимают его первыми, затем Okta строит на нём компанию, быстрее всего документ комитета превратился в доход. Вы открываете приложение.
Процесс входа: приложение → поставщик удостоверений → обратно через ваш браузер
0:46 Оно не знает, кто вы, поэтому перенаправляет ваш браузер к поставщику удостоверений, скажем, к Okta вашей компании. Вы входите туда. Okta передает вашему браузеру подписанный XML-документ, который сообщает, кто вы, и браузер отправляет его обратно.
Утверждение: подпись находится внутри того, что она подписывает
0:59 Этот документ называется утверждением. В нём указано имя пользователя, и подпись находится внутри него, указывая на утверждение по его ID. И всё это проходит через ваш браузер, то есть, через пользователя. Чтобы проверить его, приложение
Канонизация: совпадение до каждого байта, иначе никто не войдет
1:11 восстанавливает точные байты, которые были подписаны. Оно вырезает подпись, нормализует пробелы и порядок атрибутов, и хеширует результат. Это канонизация, и если две стороны расходятся хотя бы на один байт, никто не входит. Веб-токен JSON делает это по-другому. Заголовок, полезная нагрузка и подпись расположены рядом, разделенные точками. Ничего не нужно вырезать сначала.
2012 год: проверяющий и читатель смотрят на разные элементы
1:32 Вот в чём проблема. Код, который проверяет подпись, и код, который считывает имя пользователя, часто представляют собой две разные части. В две тысячи двенадцатом году статья под названием «О взломе SAML» показала, что можно переместить подписанное утверждение туда, где читатель его игнорирует, и поместить второе туда, где он его ищет. Salesforce и Shibboleth были среди одиннадцати, кто попался на эту уловку. В две тысячи восемнадцатом году Duo показал, что комментарий внутри имени пользователя может заставить некоторые
2018 и 2025 годы: два парсера, два разных ответа
1:55 библиотеки считывать только половину имени, в то время как подпись всё ещё проходит проверку. В две тысячи двадцать пятом году GitHub обнаружил два XML-парсера внутри ruby SAML, расходящиеся во мнениях относительно одного и того же документа. Та же ошибка, новое десятилетие. Trail of Bits называет это фракталом, потому что на каждом уровне, на который вы приближаетесь,
Почему он постоянно ломается: фрактал плохого дизайна
2:12 есть тот же недостаток. Он построен на XML, подпись инкапсулирована, и реальные входы используют, возможно, десятую часть спецификации. И главный ответ на Hacker News поступает от покупателя. Если у вас нет поддержки SAML, я могу найти продукт, который её имеет. Оба утверждения верны, что и является проблемой. Итак, понедельник. Сначала SHIP OpenID Connect, Fly и Tailscale продают
Понедельник: сначала OIDC, поддерживаемая библиотека, строгие формы
2:31 предприятиям вообще без SAML. Если клиент настаивает, используйте поддерживаемую библиотеку, регулярно обновляйте её, и отклоняйте сообщения, которые не похожи на те, что отправляют Okta или Google. Никогда не пишите свою собственную проверку подписи.
Вердикт, изнутри: REVERT
2:43 Вердикт, изнутри. REVERT. Почти двадцать пять лет, один класс ошибок, который никогда не умирает, и исправление, с которым все согласны, — это другой протокол. В прошлую субботу я разбирал ключи доступа, так что скажите мне, что открыть следующим в комментариях. И это The Daily Diff на сегодня. Я Нико из Axrisi. Выполняйте слияние ответственно.
Источники
- Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
- Hacker News threadnews.ycombinator.com
- Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
- Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
- GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog



