Common Pitfalls Of Custom SAML Implementations

Photo by NeONBRAND on Unsplash

SAML, the “Security Assertion Markup Language”, is an XML based markup language used to facilitate identity checks on larger-scale applications. Today, let’s talk about some common mistakes developers make when developing custom SAML solutions, how they can cause vulnerabilities, and how these vulnerabilities can be prevented.

Crash Course in SAML

SAML is used for exchanging authentication and authorization data between identity providers and service providers. One of the most common use cases for SAML is facilitating browser-based Single Sign-On (SSO).

SSO is a feature that allows users to access multiple services without logging in multiple times. For example, if you are logged into example.com, you wouldn’t have to reenter your credentials to use example-messenger.com.

The implementation of SSO is easy if the services are located under the same parent domain since browser cookies can be shared across subdomains.

Set-Cookie: cookie=abc123; Domain=example.com; Secure; HttpOnly

However, cookies cannot be shared across different domains. So example.com and example-messenger.com cannot share cookies, because they don’t share a common parent domain:

www.example.com
www.example-messenger.com

This is where SAML comes into play. SAML enables SSO by facilitating information exchange between three parties: the user, the identity provider, and the service provider. The user is you, who has the right to access your information on a website. The identity provider refers to the server that is in charge of authenticating the user and passing on user information to the service provider. The service provider refers to the actual site that the user intends to access (in this example, example.com, and example-messenger.com). This is how the process works:

The SAML response contains an identity assertion that communicates the user’s identity to the service provider. These are usually uniquely identifiable information like the username, email address, or user ID of the user. Take a look at this (oversimplified!) SAML identity assertion. It communicates the user’s identity via the user’s username.

<saml:AttributeStatement>
   <saml:Attribute Name="username">
       <saml:AttributeValue>
           user1
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

Note that in reality, the SAML response isn’t always passed in plain XML format. It is often encoded in base64 or other encoding schemes.

This system allows companies with multiple web services to only manage a centralized source of user credentials (the identity provider), instead of keeping track of users for each site. It also eliminates the need for users to log in multiple times when using the services provided by the same company.

SAML Security Considerations

Since the identity assertion within the SAML response communicates the user’s identity to the service provider, if an attacker can forge the identity assertion, they can assume the identity of others.

For example, if the attacker can change the embedded username in this SAML assertion, they can log in as another user.

<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

Therefore, most SAML implementations incorporate a signature within their SAML responses to prevent hackers from tampering with the assertions.

<saml:Signature>
        ......
     <saml:SignatureValue>
        dXNlcjE=
     </saml:SignatureValue>
         ......
</saml:Signature>
......
<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

SAML Signature Misconfigurations

However, these signature-based security measures are not always well implemented. Here are some flaws that have been found in insecure SAML solutions.

The Signature Does Not Exist Or Is Not Verified

First, if the SAML signature is not implemented or is not verified at all, the identity assertions are not protected. Attackers can forge the identity information in the SAML response at will.

The Signature is Only Verified When It Exists

Sometimes, developers make the mistake of only verifying signatures if they exist. In this case, attackers can empty out the signature field or remove the field completely to bypass the security measure.

The Signature Generated is Predictable

Lastly, if the signing mechanism used is weak or predictable, attackers can forge their own signatures! Take a look at this example we used from above:

<saml:Signature>
        ......
     <saml:SignatureValue>
        dXNlcjE=
     </saml:SignatureValue>
         ......
</saml:Signature>
......
<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

Notice that dXNlcjE= is just the base64 encoding of user1! We can deduce that the signature mechanism used is simply base64(username). So, to forge a valid identity assertion for victim_user, we can change the signature field to base64(“victim_user”), which is dmljdGltX3VzZXI=. Using this forged assertion, we can obtain a valid session as victim_user.

<saml:Signature>
        ......
     <saml:SignatureValue>
        dmljdGltX3VzZXI=
     </saml:SignatureValue>
         ......
</saml:Signature>
......
<saml:AttributeStatement>
   <saml:Attribute Name="abc">
       <saml:AttributeValue>
           victim_user
       </saml:AttributeValue>
   </saml:Attribute>
</saml:AttributeStatement>

Encryption Only SAML

Another common pitfall of SAML implementations is trusting that encryption alone will provide adequate security for the assertion. Encryption protects a message’s confidentiality, but not its integrity.

If a SAML response is encrypted but not signed—or signed with a weak signature—attackers can attempt to tamper with the encrypted message to mess with the outcome of the identity assertion.

Note that there are actually many ways of tampering with encrypted messages without having to break the encryption! But that is a topic for another day.

Injection Via SAML

As with all user input, SAML messages should be sanitized before being used. Otherwise, depending on how the elements in the SAML response is used, attackers might be able to achieve SQL injection, stored-XSS, XXE, and a whole host of other nasty web attacks.

Preventing SAML Vulnerabilities

Thankfully, there are many reliable steps that you can take to prevent SAML attacks.

Use Reputable, Out-of-box SAML Solutions, Don’t Build It Yourself!

The best way to prevent faulty SAML implementations from ruining your security is to use a reputable, out-of-the-box SAML solution instead of building it yourself. Reputable SAML products on the market are often extensively tested and have stood the test of time.

And be sure to follow the instructions of your vendor when integrating the product, as a misconfiguration can lead to vulnerabilities even when the implementation is solid.

If You Have to Build It Yourself…

If you need a custom SAML implementation, take the following precautions to minimize the chances of attack.

Encrypt and Sign

Use strong encryption and signature algorithms, and protect your secret keys at all cost! Even if you are encrypting your SAML responses, always ensure that the encrypted messages are signed as well!

Do Not Transport Sensitive Information in SAML Messages

Do not transport sensitive user information such as passwords in the SAML responses! Only transport information that is necessary for identifying the user. This will ensure that a user’s private information cannot be compromised via a single stolen session.

Treat All Input Touched By the User as Polluted

All input coming from SAML messages that touched the user should be treated as polluted. And they should always be sanitized before being processed or stored! After all, XML is just another way that user input can get into your databases and your code!

Follow SAML Security Specifications to a T

Above all, make sure that you follow the tried-and-true SAML security best practices to a T! Here are a few resources to help you do that.

• OWASP SAML Cheatsheet
• SAML Specifications

Keep an Eye On Vulnerability Disclosures

Finally, make sure that you keep an eye on vulnerability disclosures related to the identity products that you use. Naive vulnerabilities like the ones mentioned above are unlikely to be an issue in mature SAML solutions. But researchers occasionally still discover severe bugs that could lead to DoS, privilege escalation, and information disclosure.