Vulnerabilidades comunes de SAML y cómo corregirlas

Security Assertion Markup Language (SAML) es un marco basado en XML que desempeña un papel fundamental para permitir una gestión segura de identidades y accesos. Actúa como intermediario de confianza entre distintas entidades de un ecosistema digital, como proveedores de identidad, proveedores de servicios y usuarios. El propósito principal de SAML es facilitar el inicio de sesión único (SSO), un proceso de autenticación fluido y eficiente que permite a un usuario acceder a varias aplicaciones y servicios con un solo conjunto de credenciales. Aunque SAML ofrece muchas ventajas frente a la autenticación tradicional con nombre de usuario y contraseña, aún pueden producirse vulnerabilidades según lo siguiente: 

1. La biblioteca de SAML que usa un desarrollador

2. La configuración de SAML que usa un desarrollador

Este artículo ofrece un breve resumen de las vulnerabilidades más comunes de SAML y explica cómo corregirlas con algunos ejemplos.

Vulnerabilidades comunes de SAML

Validación de firmas y firma de mensajes 

La validación de aserciones XML puede ayudar a prevenir ataques de manipulación de XML. Confirma la autenticidad de los mensajes XML dentro de las aserciones de SAML. La envoltura de firmas XML es una vulnerabilidad que aprovecha debilidades en la forma en que se procesan las firmas XML y puede permitir la manipulación maliciosa de los datos.

En el siguiente ejemplo (VulnerableSAMLApp), cuando se inicia sesión como usuario normal, la siguiente información aparece en el perfil del usuario una vez que se autentica.

Es posible elevar los privilegios de este usuario modificando la solicitud de SAML y cambiando la pertenencia al grupo para que sea de administradores.

Para corregir un problema como este, es necesario hacer varias cosas:

1. Las aserciones deben estar firmadas. Esto agregará una firma al atributo de la aserción, que se firma con el certificado de confianza.

2. Se deben validar los valores de las aserciones para garantizar que las firmas coincidan con los datos del mensaje completo, incluida la aserción.

La mayoría de las bibliotecas modernas de SAML tienen opciones que se pueden habilitar para permitir la firma y validación de mensajes. Aquí puedes ver un ejemplo en samlify: https://github.com/tngan/samlify/blob/master/docs/sp-configuration.md 

Cifrado débil

En la autenticación SAML, es esencial cifrar ciertas partes del mensaje SAML para garantizar la seguridad y confidencialidad de los datos sensibles. En concreto, es necesario cifrar las aserciones de SAML, que contienen información sobre el usuario y sus atributos. Estas aserciones se intercambian entre el proveedor de identidad (IdP) y el proveedor de servicios (SP) para verificar la identidad y los permisos del usuario.

1const idp = IdentityProvider({
2  isAssertionEncrypted: true,
3  metadata: fs.readFileSync('./metadata_idp.xml'),
4  dataEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#aes256-cbc',
5  keyEncryptionAlgorithm: 'http://www.w3.org/2001/04/xmlenc#rsa-1_5' 
6});
7An example on setting the encryption on an IdentityProvider when using Samilify: https://github.com/tngan/samlify/blob/master/docs/encrypted-saml-response.md

Vencimiento de los mensajes

De forma predeterminada, los mensajes SAML pueden ser vulnerables a ataques de repetición. En un ataque de repetición, se reutiliza sin autorización un mensaje SAML válido que fue interceptado, con la intención de suplantar una acción legítima de SAML, como el inicio de sesión único (SSO) o el cierre de sesión único (SLO).   Los atributos "NotBefore" y "NotOnOrAfter" pueden ayudar a prevenir estos ataques.

• NotBefore (atributo): Este atributo define el momento más temprano en que la aserción de SAML puede considerarse válida. En otras palabras, la aserción no debe usarse para la autenticación o autorización antes de la hora especificada en "NotBefore". Esto garantiza que la aserción no se use antes de tiempo, algo especialmente importante en operaciones sujetas a plazos. Por lo general, la aserción se considera no válida antes de la hora indicada en "NotBefore".

• NotOnOrAfter (atributo): Este atributo especifica el último momento en que la aserción de SAML sigue siendo válida. Una vez transcurrida la hora indicada en "NotOnOrAfter", la aserción no debe usarse para la autenticación ni la autorización. Esta restricción de tiempo ayuda a prevenir el uso indebido de aserciones desactualizadas que podrían haberse interceptado u obtenido de forma maliciosa.

Redirección abierta

SAML es, por naturaleza, un protocolo asíncrono. Cuando comienza un proceso de inicio de sesión iniciado por el SP, este crea una solicitud de autenticación SAML y la envía al proveedor de identidad (IdP). En ese momento, el proveedor de servicios no conserva ninguna información sobre la solicitud. Por lo tanto, cuando recibe la respuesta SAML del IdP, desconoce el enlace profundo original que inició la solicitud de autenticación. SAML aborda este problema mediante un parámetro esencial llamado "RelayState".

RelayState funciona como un parámetro HTTP y se puede incluir tanto en la solicitud como en la respuesta SAML. Cuando hay un flujo de inicio de sesión iniciado por el SP, este puede usar el parámetro RelayState para incluir información adicional en la solicitud SAML. Así se garantiza que el contexto y los datos esenciales no se pierdan durante el proceso asíncrono. Sin embargo, un atacante puede aprovechar el parámetro RelayState para llevar a cabo ataques de redirección abierta.

Para evitar ataques de redirección abierta, confirma que el valor de RelayState sea una URL de confianza antes de redirigir. Aquí puedes ver un ejemplo proporcionado por los encargados de mantener la biblioteca python3-saml.

Conclusión

En este análisis de las vulnerabilidades comunes de SAML y cómo corregirlas, vimos algunos ejemplos. Sin embargo, cabe señalar que estas correcciones pueden variar o, en algunos casos, no ser posibles, según la biblioteca de SAML y el proveedor de identidad que uses. Por ello, debes consultar la documentación de estas bibliotecas y proveedores externos para saber cómo prevenir eficazmente estas vulnerabilidades. 

Por último, aunque SAML ofrece un marco para la gestión segura de identidades y accesos, OpenID Connect (OIDC) puede ser una buena alternativa que no usa XML. OIDC es una capa de identidad moderna construida sobre OAuth 2.0 y JWT. En lugar de usar aserciones basadas en XML, OIDC usa JSON Web Tokens (JWT) para transmitir información de identidad, por lo que es más adecuado para aplicaciones web y móviles modernas. OIDC puede simplificar el proceso de integración y ofrece funciones como la recuperación de información del perfil del usuario, lo que lo convierte en una opción atractiva para los desarrolladores que prefieren no trabajar con la seguridad de XML. Muchos de los ataques mencionados en este artículo no se aplican a OIDC. Por eso, OIDC puede ser una alternativa que vale la pena considerar, y su adopción podría mitigar parte de la complejidad asociada con SAML.