Здравствуйте, дорогие друзья.

Идея XML Signature Wrapping (XSW) заключается в использовании разделения между службой единого входа (SSO) cредством проверки и процессором единого входа (SSO Processor). Это возможно, поскольку XML-документы, содержащие XML-подписи обычно обрабатываются в два отдельных этапа: один раз для проверки цифровой подписи и один раз для приложения, использующего XML-данные.

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

Если вы проводите тестирование на наличие уязвимостей такого типа, я бы порекомендовал использовать плагин SAML Raider для Burp, как показано ниже:

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

Атака XSW 1

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

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

XSW-атака 2

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

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

Атака XSW 3

Эта атака работает путем размещения нашего вредоносного утверждения над исходным утверждением, поэтому оно является первым элементом в ответе SAML.

Мы надеемся, что после завершения этапов проверки в процессе синтаксического анализа будет использован первый элемент в SAML-ответе. Если это произойдет, он перехватит наше вредоносное утверждение вместо исходного.

XSW-атака 4

Эта атака похожа на атаку XSW 3, за исключением того, что мы вставляем исходное утверждение в наше утверждение evil, как показано ниже:

Атака XSW 5

В ходе этой атаки мы копируем исходную подпись и внедряем ее в наше вредоносное утверждение. Однако исходная подпись по-прежнему указывает на исходное утверждение, как показано на рисунке ниже.

XSW-атака 6

Здесь мы вставляем исходное утверждение в исходную подпись, затем мы вставляем все это в вредоносное утверждение, как показано ниже:

Атака XSW 7

В этом методе используется тег “Extensions”, который является менее ограничивающим элементом XML. Здесь мы помещаем вредоносное утверждение с тем же идентификатором, что и исходное утверждение, в набор тегов extensions.

Обратите внимание, что вредоносное утверждение и исходное утверждение имеют один и тот же идентификатор.

XSW-атака 8

Мы снова используем менее ограничительный XML-элемент под названием “Object”. Сначала мы создаем вредоносное утверждение и вставляем в него исходную подпись. Затем мы вставляем элемент object в подпись и, наконец, помещаем исходное утверждение в элемент object.

Обратите внимание, что вредоносное утверждение и исходное утверждение имеют один и тот же идентификатор.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.