Common SAML vulnerabilities and how to remediate them

Security Assertion Markup Language (SAML) is an XML-based framework that plays a pivotal role in enabling secure identity and access management. It acts as a trusted intermediary between various entities in a digital ecosystem, such as identity providers, service providers, and users. The primary purpose of SAML is to facilitate single sign-on (SSO), a seamless and efficient authentication process where a user can access multiple applications and services using a single set of credentials. While SAML offers many benefits over traditional username and password authentication, vulnerabilities can still occur depending on the: 

1. SAML library used by a developer

2. SAML settings used by a developer

This blog aims to give a short overview of popular SAML vulnerabilities and how they can be remediated with some examples.

Common SAML Vulnerabilities

Signature validation and message signing 

XML assertion validation can be used to prevent XML tampering attacks. It confirms the authenticity of XML messages within SAML assertions. XML signature wrapping is a vulnerability that exploits weaknesses in the way XML signatures are processed and can lead to malicious manipulation of the data.

In the below example (VulnerableSAMLApp), when authenticating as a normal user, the following information is shown on a user’s profile once they authenticate.

It is possible to elevate the privileges of this user by modifying the SAML request and changing the group membership to be administrators.

In order to remediate an issue such as this, multiple things will need to be done:

1. Assertions must be signed. This will add a signature to your assertion attribute, which is signed with the trusted certificate.

2. Assertion values must be validated to ensure the signatures match the data in the overall message, including the assertion.

Most modern SAML libraries will have settings that can be enabled to allow message signing and validation. An example of this within samlify can be seen here: https://github.com/tngan/samlify/blob/master/docs/sp-configuration.md 

Weak encryption

In SAML authentication, it's essential to encrypt certain portions of the SAML message to ensure the security and confidentiality of sensitive data. Specifically, the SAML assertions, which contain information about the user and their attributes, need to be encrypted. These assertions are exchanged between the Identity Provider (IdP) and the Service Provider (SP) to verify the user's identity and permissions.

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

Message expiration

SAML messages, by default, can be vulnerable to replay attacks. A replay attack involves the unauthorized reuse of a valid intercepted SAML message intending to impersonate a legitimate SAML action, such as single sign-on (SSO) or single logout (SLO).   "NotBefore" and "NotOnOrAfter" can be used to prevent these attacks.

• NotBefore (Attribute): This attribute defines the earliest time at which the SAML assertion can be considered valid. In other words, the assertion should not be used for authentication or authorization before the specified "NotBefore" time. It ensures that the assertion is not prematurely used, which is particularly important when dealing with time-sensitive operations. Before the "NotBefore" time, the assertion is typically considered invalid.

• NotOnOrAfter (Attribute): This attribute specifies the latest time at which the SAML assertion remains valid. After the "NotOnOrAfter" time has passed, the assertion should not be used for authentication or authorization. This time constraint helps prevent the misuse of outdated assertions that might have been intercepted or obtained maliciously.

Open redirect

SAML is inherently an asynchronous protocol. When an SP-initiated sign-in process commences, it initiates by crafting a SAML authentication request, which is then directed to the Identity Provider (IdP). Crucially, at this juncture, the Service Provider does not retain any information concerning the request. Consequently, when the SAML response is received from the IdP, the Service Provider remains oblivious to the original deep link that prompted the authentication request. SAML addresses this issue with the incorporation of a vital parameter known as "RelayState."

The RelayState serves as an HTTP parameter and can be incorporated into both the SAML request and SAML response. In scenarios where an SP-initiated sign-in flow is underway, the SP can employ the RelayState parameter to embed supplementary information within the SAML request. This mechanism ensures that essential context and data are not lost during the asynchronous process. However, this RelayState parameter can be abused by an attacker to conduct open redirect attacks

To avoid open redirect attacks, confirm the value of the RelayState is a trusted URL before redirection. Here is an example provided by the maintainers of the python3-saml library.

Conclusion

We've delved into some examples in this exploration of common SAML vulnerabilities and their remediation, but it should be noted depending on the SAML library Identity Provider you are using — some of these remediations might look different or, in some cases, might not be possible. As such, the documentation of these libraries and third party providers should be reviewed to ensure how to prevent these vulnerabilities effectively. 

Lastly, while SAML provides a framework for secure identity and access management, OpenID Connect (OIDC) can be a nice alternative to SAML that doesn’t use XML. OIDC is a modern identity layer built on top of OAuth 2.0 and JWT. Instead of using XML-based assertions, OIDC relies on JSON Web Tokens (JWTs) to convey identity information, making it more suitable for modern web and mobile applications. With OIDC, the integration process can be simplified, and it offers features like user profile information retrieval, making it an attractive option for developers who don't want to dabble with XML security. Many of the attacks mentioned in this blog are not applicable to OIDC. As such, OIDC might be a worthy alternative to consider, and its adoption could mitigate some of the complexities associated with SAML.