How to Spot Vulnerabilities of Custom SAML Implementations Before They Happen
This article will go over roadblocks developers might come in contact with when working with the custom SAML solutions and preventive measures.
Join the DZone community and get the full member experience.Join For Free
SAML (Security Assertion Markup Language) is often prone to vulnerabilities as an XML based markup language used to expedite identity checks for bigger applications. This article will go over the usual roadblocks developers might come in contact with when working with the custom SAML solutions, as well as looking into preventative measures for developers to take, stopping vulnerabilities before they happen.
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
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-messenger.com cannot share cookies, because they don’t share a common parent domain:
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-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.
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.
Therefore, most SAML implementations incorporate a signature within their SAML responses to prevent hackers from tampering with the assertions.
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:
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
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.
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.
Published at DZone with permission of Vickie Li, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.