SAML Vulnerability: What You Need to Know

Single sign-on (SSO) is a convenient and secure way of accessing multiple web applications without requiring individual credentials for each. However, if not implemented properly, SSO can also introduce serious security risks. One of the most common technologies used for SSO is the Security Assertion Markup Language (SAML), which is an open standard for exchanging authentication and authorization information.

What is SAML and how does SAML work?

SAML is a markup language based on XML that defines a set of protocols, bindings, and assertions for exchanging security information between an identity provider (IdP) and a service provider (SP). The IdP is an application that authenticates users and issues assertions about their identity and attributes. The SP is an application that relies on the IdP’s assertions to grant users access to its protected resources. The user’s browser acts as an intermediary that transfers messages between the IdP and the SP.

The basic flow of SAML authentication is as follows:

The user requests access to a resource on the SP’s website.
The SP redirects the user to the IdP’s website with an authentication request (AuthnRequest) that contains information such as the SP’s identifier, the requested assertion type, and the return URL known as SAML Request.
The IdP authenticates the user using its own methods (such as username and password, multifactor authentication, etc.) and generates a response (SAML Response) that contains an assertion (Assertion) that attests to the user’s identity and attributes.
The IdP sends the response back to the user’s browser, which forwards it to the SP’s return URL.
The SP validates the response and extracts the assertion from it. The SP then uses the assertion to grant or deny access to the user based on its own policies.

If you see the basic flow of SAML, it can be much more simple in comparison with [OAuth 2.0](https://binaryte.com/blog/understanding-o-auth-2-0-and-open- id-a-comprehensive-guide) which is also an SSO technology. However, it differs one to another due to the fact that SAML is used for authentication while OAuth 2.0 is used for authorization. SAML is an old technology, yet still used by lots of companies as it simplifies the authentication process for users and reduces the number of passwords they have to remember. It also enhances security by minimizing the exposure of credentials and enabling centralized management of identities and access policies.

SAML message example

From the previous section, we know that both the SAML Request and the SAML Response are involved. Here is an example of SAML Request.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                   ID="abcdefghi"
                   Version="2.0"
                   IssueInstant="2023-09-07T03:50:39Z"
                   Destination="https://idp.example.com/saml/sso"
                   AssertionConsumerServiceURL="https://sp.example.com/saml/acs">
 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://sp.example.com/saml/metadata</saml:Issuer>
 <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
                     AllowCreate="true"/>
 <samlp:RequestedAuthnContext Comparison="exact">
   <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0acclassesassword</samlAuthnContextClassRef>
 </samlpRequestedAuthnContext>
</samlpAuthnRequest>

The request contains the following elements:

ID, Version, IssueInstant, Destination, and AssertionConsumerServiceURL are attributes that identify the request and provide information about where to send the response.
Issuer is the entity that issued the request, in this case, the SP.
NameIDPolicy is the element that specifies the format and creation policy of the user identifier (NameID) in the response.
RequestedAuthnContext is the element that specifies the desired authentication context class and comparison method for the authentication event.

Here is an example of SAML Response.

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
               ID="123456789"
               Version="2.0"
               IssueInstant="2023-09-07T03:50:39Z"
               Destination="https://sp.example.com/saml/acs"
               InResponseTo="abcdefghi">
 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.example.com/saml</saml:Issuer>
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <!-- Signature omitted for brevity -->
 </ds:Signature>
 <samlp:Status>
   <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
 </samlp:Status>
 <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                 ID="987654321"
                 Version="2.0"
                 IssueInstant="2023-09-07T03:50:39Z">
   <saml:Issuer>https://idp.example.com/saml</saml:Issuer>
   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <!-- Signature omitted for brevity -->
   </ds:Signature>
   <saml:Subject>
     <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</saml:NameID>
     <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
       <saml:SubjectConfirmationData NotOnOrAfter="2023-09-07T03:55:39Z"
                                     Recipient="https://sp.example.com/saml/acs"
                                     InResponseTo="abcdefghi"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions NotBefore="2023-09-07T03:50:39Z"
                    NotOnOrAfter="2023-09-07T03:55:39Z">
     <saml:AudienceRestriction>
       <saml:Audience>https://sp.example.com/saml/metadata</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement AuthnInstant="2023-09-07T03:50:39Z"
                        SessionIndex="123456789">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0acclassesassword</samlAuthnContextClassRef>
     </samlAuthnContext>
   </samlAuthnStatement>
 </samlAssertion>
</samlpResponse>

The response contains the following elements:

ID, Version, IssueInstant, Destination, and InResponseTo are attributes that identify the response and link it to the corresponding request.
Issuer is the entity that issued the response, in this case, the IdP.
Signature is the digital signature that verifies the authenticity and integrity of the response.
Status is the status code that indicates whether the authentication was successful or not.
Assertion is the core element that contains the information about the user and the authentication event.
Assertion ID, Version, and IssueInstant are attributes that identify the assertion and its creation time.
Assertion Issuer is the same as the response issuer, in this case, the IdP.
Assertion Signature is the digital signature that verifies the authenticity and integrity of the assertion.
Subject is the element that identifies the user, in this case, by an email address (NameID).
SubjectConfirmation is the element that confirms that the user is the bearer of the assertion and provides additional information such as the expiration time (NotOnOrAfter), the recipient (Recipient), and the request ID (InResponseTo).
Conditions is the element that specifies the validity conditions of the assertion, such as the time window (NotBefore and NotOnOrAfter) and the intended audience (AudienceRestriction).
AuthnStatement is the element that describes the authentication event, such as the authentication time (AuthnInstant), the session identifier (SessionIndex), and the authentication method (AuthnContext).

What are some common SAML vulnerabilities and how to exploit it?

SAML vulnerabilities are flaws or weaknesses in SAML implementations that allow an attacker to bypass authentication or authorization checks and gain access to protected resources or information. Some of the common types of SAML vulnerabilities are:

XML External Entities (XXE) Injection

SAML messages are based on XML, which is a structured and hierarchical data format. If the SP does not properly validate or sanitize the XML input, an attacker can inject malicious XML elements or attributes into the SAML message and cause unexpected behavior or damage. For example, an attacker can use [XML external entities (XXE)](https://binaryte.com/blog/xml-external-entities-xxe- injection) to access or disclose local files or network resources, or use XML signature wrapping (XSW) to modify or forge the signed content of the message.

To exploit this vulnerability, an attacker can use a tool such as SoapUI to craft and send malicious XML messages to the SP. Alternatively, an attacker can use a browser extension such as SAML Tracer to modify the SAML messages in transit.

Assertion Tampering

SAML assertions contain the information that the SP relies on to grant or deny access to the user, such as the user’s identity, attributes, and roles. If the SP does not verify the integrity and authenticity of the assertion, an attacker can tamper with the assertion and change its content or meaning. For example, an attacker can change the user’s email address, name, or role to impersonate another user or gain higher privileges.

To exploit this vulnerability, an attacker can use a tool such as Burp Suite to intercept and modify the SAML assertion before sending it to the SP. Alternatively, an attacker can use a tool such as SamlTool to generate a forged SAML assertion and send it to the SP.

SAML Security Risks and Best Practices

One of the most important best practices for implementing SAML in applications is to limit the XML parser that is used to validate and process SAML messages. A strict and secure XML parser can help avoid many of the vulnerabilities that stem from malformed or malicious XML input.

XML parsers are software components that read, interpret, and manipulate XML documents. They are essential for SAML because they enable the exchange of authentication and authorization data between parties. However, not all XML parsers are created equal. Some XML parsers are more lenient and flexible than others, allowing them to handle various types of XML input, such as invalid, incomplete, or non-standard XML documents. While this may seem convenient, it also opens the door for potential attacks.

An attacker can exploit a weak or vulnerable XML parser by crafting a malicious XML document that contains harmful elements, such as external entities, comments, processing instructions, or signatures. These elements can cause the XML parser to execute arbitrary code, access sensitive data, or perform denial-of-service attacks on the receiver. For example, an attacker can inject a malicious external entity reference into a SAML message and cause the receiver to access a file on their system or a remote URL that contains malicious code.

To prevent these and other types of attacks, developers should use a strict and secure XML parser that follows the XML specification and rejects any malformed or malicious XML input. A strict and secure XML parser can help ensure the integrity and confidentiality of SAML messages by verifying their signatures, validating their schemas, and limiting their external entities. Developers should also use other security measures, such as encryption, digital signatures, certificates, and nonce values, to enhance the security of SAML messages. By following these best practices, developers can leverage the benefits of SAML while minimizing the risks.

Conclusion

SAML is a widely used technology for implementing SSO solutions that provide convenience and security for users and applications. However, SAML also has some vulnerabilities that can be exploited by attackers to bypass authentication or authorization checks and gain access to protected resources or information. Therefore, it is important to understand what SAML is, how it works, what are the common vulnerabilities associated with it, how to exploit them, what are the impacts and risks of doing so, and how to prevent and mitigate them. By following the best practices and recommendations for securing SAML implementations, such as enforcing message confidentiality and integrity, validating protocol usage and processing rules, implementing security countermeasures, and testing and auditing SAML configurations and messages, you can protect your SSO service from SAML vulnerabilities and ensure a safe and reliable user experience.

We hope you found this article informative and helpful. If you want to learn more about SAML vulnerability or SSO security, you can check out some of the resources we used for this article . You can also contact us for any questions or feedback. Thank you for reading!