Предоставляют ли SAML-ответы, содержащие зашифрованные утверждения, защиту от атак “человек посередине”?

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

В веб-приложении, которое я тестирую, SAML SSO обеспечивается с помощью Keycloak. Сообщения SAML Response содержат зашифрованные утверждения (<saml:EncryptedAssertion>). Перед зашифрованным утверждением находится Подпись (<dsig:Signature>); если подпись убрать, SP все равно принимает аутентификацию пользователя.

1. Может ли содержимое этих сообщений быть прочитано только SP/IdP/Keycloak?
2. Могут ли новые утверждения быть зашифрованы с использованием доступного публичного ключа, заменяя оригинальное утверждение? Если да, где/как можно найти соответствующий публичный ключ?
3. Какова цель подписи, если ее удаление ничего не меняет? Это проблема с Keycloak (брокером)? Ответственность за проверку подписи лежит на SP?

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

ИЗМЕНЕНИЕ: Прикрепляю пример ответа SAML так, как я его вижу:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response Destination="https://example.com/saml/SSO"
  ID="0000000-000-000-000-00000000"
  InResponseTo="abc123abc123abc123"
  IssueInstant="2020-06-29T00:00:0000Z" Version="2.0"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sso.example.com/auth/realms/MY-APP</saml:Issuer>
  <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <dsig:SignedInfo>
      <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
      <dsig:Reference URI="#ID_0000000-000-000-000-00000000">
        <dsig:Transforms>
          <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
          <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        </dsig:Transforms>
        <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        <dsig:DigestValue>/DATA=</dsig:DigestValue>
      </dsig:Reference>
    </dsig:SignedInfo>
    <dsig:SignatureValue>DATA==</dsig:SignatureValue>
    <dsig:KeyInfo>
      <dsig:KeyName>AAAAAA-AAAAA-1234567987654321234567</dsig:KeyName>
      <dsig:X509Data>
        <dsig:X509Certificate>CERT==</dsig:X509Certificate>
      </dsig:X509Data>
      <dsig:KeyValue>
        <dsig:RSAKeyValue>
          <dsig:Modulus>DATA==</dsig:Modulus>
          <dsig:Exponent>AAAA</dsig:Exponent>
        </dsig:RSAKeyValue>
      </dsig:KeyValue>
    </dsig:KeyInfo>
  </dsig:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
          <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"/>
          <xenc:CipherData>
            <xenc:CipherValue>DATA==</xenc:CipherValue>
          </xenc:CipherData>
        </xenc:EncryptedKey>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>LONG_DATA==</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </saml:EncryptedAssertion>
</samlp:Response>

Я тоже не до конца понимаю сервис Keycloak, но вот основы SAML Response (от IdP к SP), если только IdP и SP не согласовали сделать что-то другое:

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

Таким образом, чтобы осуществить атаку MITM с заменой содержимого, MITM должен иметь публичный ключ SP. Таким образом, если SP не выставляет свой публичный ключ в интернете, его видят только IdP и сам SP. Кроме того, SP должен пропустить проверку подписи. Снова, я не вижу никаких библиотек, которые делают это по умолчанию.

Но вернемся к вашему вопросу…

1. Может ли содержимое этих сообщений быть прочитано только SP/IdP/Keycloak?

Оригинальное зашифрованное содержимое видно только IdP (кто генерирует содержимое) и тем, кто имеет приватный ключ IdP.

2. Могут ли новые утверждения быть зашифрованы с использованием доступного публичного ключа, заменяя оригинальное утверждение? Если да, где/как можно найти соответствующий публичный ключ?

Определенно. В соответствии с протоколом IdP публикует свою SAML2 метаданные в интернете, чтобы их клиенты могли проверить подпись.

3. Какова цель подписи, если ее удаление ничего не меняет? Это проблема с Keycloak (брокером)? Ответственность за проверку подписи лежит на SP?

Любое зашифрованное сообщение без подписи недостоверно. Его не следует принимать.

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

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

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

Смотрите этот документ об атаках обертывания подписи XML.
https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf