XML Signature wrapping, или XSW, — это атака на приложения, которые проверяют цифровую подпись XML, но затем обрабатывают не тот узел, который был подписан. Чаще всего проблема встречается в SAML, SOAP и WS-Security, где структура XML влияет на логику аутентификации и авторизации.
Содержание статьи
Что означает XML Signature wrapping
XML Signature wrapping — это подмена обрабатываемых XML-данных без поломки цифровой подписи. Атакующий сохраняет подписанный фрагмент в документе, но добавляет рядом другой, неподписанный, который приложение принимает за основной.
Суть уязвимости строится на разрыве между двумя этапами: проверкой подписи и чтением данных. Валидатор может честно подтвердить, что подпись верна и исходный подписанный элемент в документе присутствует. Но код приложения затем берет другой элемент — по имени тега, по позиции в дереве XML или по слишком широкому XPath-выражению.
Из-за этого система видит «валидную подпись», хотя реально использует данные, которые никто не подписывал. В контексте SAML это может означать чужую роль, другой NameID или подмену атрибутов доступа.
Как связаны XML и XML-подпись
XML — это текстовый формат представления структурированных данных. XML Signature — стандарт цифровой подписи, который позволяет подтвердить целостность конкретного фрагмента XML-документа.
XML хранит данные в виде вложенных элементов и атрибутов. Такой формат удобен для обмена сообщениями между системами, поэтому его давно используют в протоколах идентификации и веб-сервисах. Отсюда и типичные зоны риска: SAML-ответы, SOAP-сообщения, элементы WS-Security.
Подпись в XML обычно не охватывает весь документ целиком. Чаще подписывают отдельный узел, на который указывает ссылка в блоке подписи. Именно эта особенность и открывает путь для XSW, если приложение не связывает результат валидации с тем узлом, который потом идет в обработку.
Как обычно формируется XML-подпись
Подпись XML строится вокруг ссылки на конкретный элемент и криптографической проверки его содержимого. Проверяется не «документ вообще», а строго заданный объект.
- Выбирается XML-элемент для подписи через ссылку вида URI с идентификатором.
- Для выбранных данных вычисляется хэш.
- Хэш подписывается закрытым ключом отправителя.
- В XML добавляется блок Signature со служебными полями, значением подписи и данными ключа или сертификата.
Почему подпись может быть валидной, а данные — поддельными
Подпись остается валидной, если подписанный узел не изменили. Атакующему не нужно ломать криптографию. Ему достаточно переместить исходный узел в другое место документа и подставить на рабочую позицию новый.
Если приложение сначала проверяет ссылку в Signature, а потом ищет нужный элемент отдельно, появляется расхождение. Проверка проходит для одного узла. Бизнес-логика читает другой.
Как работает атака XML Signature wrapping
XSW работает через подмену структуры XML. Подписанный элемент сохраняется, поэтому подпись проходит проверку, а приложение читает внедренный неподписанный фрагмент.
Типичный сценарий начинается с валидного сообщения. Это может быть SAML-ответ от поставщика удостоверений или SOAP-запрос с подписанным телом. Атакующий получает такой документ, не меняет исходный подписанный блок, но переставляет его в другую часть XML-дерева.
После этого в исходное место вставляется похожий элемент с измененными данными. Внешне он выглядит правдоподобно: те же названия тегов, та же общая форма, иногда даже те же идентификаторы. Если код приложения выбирает первый найденный Assertion или Body, он возьмет именно этот подставной узел.
Подпись при этом может успешно пройти валидацию, потому что ссылка в Signature по-прежнему указывает на настоящий, неизмененный фрагмент. Просто этот фрагмент уже не участвует в дальнейшей логике.
Короткая схема атаки
Механика XSW обычно укладывается в несколько шагов.
- Атакующий берет настоящее подписанное XML-сообщение.
- Перемещает подписанный элемент в другое место документа.
- Вставляет на исходную позицию новый элемент с нужными ему значениями.
- Оставляет блок Signature без изменений.
- Добивается ситуации, в которой валидатор проверяет один узел, а приложение обрабатывает другой.
Как это выглядит на примере SAML
В SAML-обмене XSW позволяет подменить утверждение об идентичности пользователя, не ломая исходную подпись. Если сервис доверяет не тому Assertion, атакующий может войти под чужой ролью.
SAML использует XML для передачи сведений об аутентификации между поставщиком удостоверений и сервисом. Внутри ответа часто находится Assertion — блок с идентификатором пользователя, атрибутами и условиями доступа. Этот блок обычно подписывается.
Уязвимость возникает, когда сервис-провайдер подтверждает подпись на одном Assertion, но затем для входа в систему использует другой Assertion из того же документа. Тогда подмена NameID, ролей или атрибутов может привести к захвату привилегий.
Что именно проверяет система
Корректная реализация должна удостовериться, что обработанный Assertion и подписанный Assertion — один и тот же узел. Если этого связывания нет, подпись теряет смысл как средство защиты от подмены содержимого.
Что происходит при уязвимой реализации
Сервис принимает SAML-ответ и видит валидный блок Signature. После этого прикладной код ищет Assertion по тегу или по расположению в документе. Если первым найден поддельный узел, система строит сессию уже на его основе.
Итог прост: криптография формально сработала, а аутентификация — нет.
Основные виды XML Signature wrapping
У XSW нет одного шаблона. Атаки различаются по тому, как именно злоумышленник прячет подписанный узел и какой механизм выбора данных использует приложение.
Простое оборачивание
Подписанный элемент переносят в другой раздел XML, а на его место ставят поддельный. Если приложение ориентируется на исходную позицию или на первый подходящий тег, оно читает внедренный блок.
Подмена через ID
Атака использует идентификаторы XML-элементов. Проблема появляется, когда в документе оказываются дублирующиеся или конфликтующие ID, а парсер и логика приложения по-разному выбирают «нужный» элемент.
Подмена через пространства имен
Здесь атакующий играет на различиях в обработке XML namespace, то есть пространств имен. Валидация и прикладной код могут по-разному интерпретировать один и тот же элемент, если проверка схемы или выбор узла реализованы слабо.
Злоупотребление enveloped signature
При таком подходе меняют положение блока Signature внутри подписываемого XML. Цель — добиться ситуации, при которой валидатор считает охват подписи корректным, а приложение использует фрагменты вне защищенного участка.
Подмена через XPath
Если верификация или выбор подписанных данных опираются на XPath, слишком широкие или неоднозначные выражения становятся точкой входа. Тогда можно направить проверку на безопасный узел, а обработку — на вредоносный.
Где XML Signature wrapping опаснее всего
Наибольший риск возникает там, где XML управляет входом в систему, ролями пользователя или критичными командами. Это SSO, SOAP-службы, административные операции и финансовые транзакции.
| Сценарий | Что подписано | Что подменяют | Риск |
| SAML SSO | Assertion | NameID, роли, атрибуты | Обход аутентификации, захват привилегий |
| SOAP и WS-Security | Body или его часть | Команды, параметры операции | Несанкционированные действия через сервис |
| Административные XML-команды | Команда или запрос | Цель операции | Сброс пароля, удаление учетной записи, смена прав |
| Платежные XML-запросы | Детали перевода | Сумма, получатель, реквизиты | Подмена транзакции и финансовые потери |
Общий принцип во всех случаях один. Система доверяет подписи, но исполняет данные из другого места документа. Чем выше цена ошибки в бизнес-логике, тем тяжелее последствия.
Как понять, что приложение уязвимо
Признак уязвимости — ситуация, при которой проверка подписи и выбор данных выполняются разными механизмами без жесткой связи между ними. Если приложение ищет XML-узлы по имени тега или позиции, риск XSW резко растет.
Проверка начинается с того, как система извлекает Assertion, Body или другой чувствительный элемент. Если после успешной валидации код просто вызывает поиск первого подходящего узла, это плохой сигнал. Безопасная реализация должна работать именно с тем объектом, который был подтвержден валидатором.
Отдельное внимание стоит уделять повторяющимся элементам, нестандартной вложенности, конфликтующим ID и слишком общим XPath-запросам. Также помогают тесты с переносом подписанного узла в другое место документа и вставкой дубликата на его исходную позицию.
Что проверяют во время тестирования
Набор базовых проверок обычно такой:
- Как приложение выбирает Assertion, Body или другой чувствительный элемент после валидации подписи.
- Что происходит при наличии двух однотипных элементов в одном документе.
- Как обрабатываются ID-атрибуты и нет ли конфликта ссылок.
- Используются ли широкие XPath-выражения при выборе узлов.
- Связывается ли результат криптографической проверки с конкретным XML-объектом в прикладной логике.
Как защититься от XML Signature wrapping
Главная защита от XSW — обрабатывать только тот XML-элемент, который был реально подписан и успешно проверен. Если приложение извлекает данные отдельно от механизма валидации, защита неполная.
Безопасная схема строится вокруг строгой привязки между ссылкой в Signature и объектом, который дальше участвует в логике приложения. Валидатор должен вернуть конкретный узел, и именно этот узел должен идти в аутентификацию, авторизацию или выполнение команды.
Не менее важны жесткие правила разбора XML: запрет неоднозначных конструкций, контроль ID, корректная работа с пространствами имен, ограничение количества допустимых критичных элементов. Если протокол ожидает один Assertion, документ с двумя Assertion должен отклоняться.
Практические меры защиты
Меры против XSW обычно включают и криптографическую, и прикладную часть.
- Проверять подпись на уровне доверенной библиотеки, а не собственной логикой.
- Использовать в коде именно тот узел, который вернул механизм валидации подписи.
- Запрещать дубли чувствительных элементов, если протокол их не допускает.
- Жестко обрабатывать ID-атрибуты и отклонять документы с конфликтами.
- Избегать широких XPath-выражений при выборе критичных данных.
- Проверять схему XML и ожидаемую структуру документа.
- Логировать ошибки разбора и валидации без лишней утечки внутренней информации.
Короткий чек-лист по XML Signature wrapping
XSW возможна там, где подпись подтверждает один XML-узел, а приложение использует другой. Если в системе есть SAML, SOAP или WS-Security, такую логику нужно проверять отдельно.
- XSW не ломает подпись, а обходит связь между подписью и обработкой данных.
- Частые цели атаки — SAML Assertion и SOAP Body.
- Главный дефект — выбор данных по тегу, позиции или неоднозначному XPath.
- Надежная защита требует обработки только подписанного и проверенного узла.
- Дубли критичных элементов и конфликты ID должны приводить к отклонению документа.