How SAML works and some attacks on it

Published in

stolabs

7 min readJan 6, 2023

What is SAML?

Security Assertion Markup Language (SAML) is an open standard that allows the communication between an identity providers (IdP) and a service providers (SP).

Single-sign-on (SSO) systems frequently employ the open standard Security Assertion Markup Language (SAML). The communication between a Service Provider and an Identity Provider is handled by SAML and is done via XML.

What is SAML Used For?

Users, identity providers, and service providers can all benefit from SAML’s simplified authentication and authorization processes. SAML offers a solution that separates your identity provider from your service providers, centralizing user administration and granting access to SaaS products.

SAML implements a standard pattern for transferring user authentications and authorizations between identity providers and service providers. The service provider asks the proper identity provider for authorization when a user logs into a SAML-enabled application. The user is now able to use the application after the identity provider has verified the user’s credentials and returned the user’s authorization to the service provider.

How SAML works?

The way SAML works is by providing user, login, and attribute information between the identity provider and service providers. When a user tries to access certain services, the identity provider can provide SAML attributes to the service provider once the user logs in first to Single Sign On with the identity provider. The service provider asks the identity provider for authentication and authorization.

Each identity provider and service provider need to agree upon the configuration for SAML. Both ends need to have the exact configuration for the SAML authentication to work.

SAML steps

We try to access some protected resource
The server where that resource resides (Service Provider) doesn’t know us, so it generates a SAML Request to be sent to the Identity Provider.
After generating the SAML Request, the SP redirects us to the IdP. Note: The SAML Request passes through our browser on the way to the IdP.
The IdP receives the SAML Request
The IdP provides some means of authentication; a login form or something similar.
The IdP validates us as a legitimate user that should be allowed to access the resource included as part of the SAML Request
The IdP creates a SAML Response. The SAML Response contains the SAML Assertions necessary for the SP. The Assertion usually includes the following information at a minimum: Indication that the Assertion is from the correct IdP, a NameID attribute specifying who the user is, and a digital signature. The SAML Response also passes through our browser.
The IdP redirects us to the SP’s Assertion Consumer Service (ACS) URL. The ACS is simply the URL on which the SP expects to receive SAML assertions.
The ACS validates the SAML Response.
We are allowed to access the resource we originally requested.

SAML vs OAUTH

OAuth is a slightly more recent standard that Twitter and Google jointly created to allow for more efficient internet logins. OAuth shares login information in a way similar to SAML. OAuth is better on mobile and uses JSON, however SAML gives businesses greater control to keep their SSO logins more secure.

SAML Request Example

When accessing a service provider without first getting authentication, it will usually create a SAML that seems like follows:

AssertionConsumerServiceURL: Identifies where the IdP should send the SAML Response to after authentication
Destination: Indicates the address to which the request should be sent (IdP)
ProtocolBinding: Typically accompanies the AssertionConsumerServiceURL attribute; defines the mechanism by which SAML protocol messages will be transmitted
saml:Issuer: Identifies the entity that generated the request message

With the SAML Request created, the SP now replies to our request with a 302 redirect. The 302 directs our browser to head over to the IdP. The SAML Request is encoded into the HTTP response’s Location header as part of the 302.

The RelayState parameter, which the SP sends to the IdP along with the SAML Request, contains state data so that the SP will know who requested the resource when the SAML Response is returned. The RelayState value must be the same in the SAML Response.

The SAMLRequest parameter is a compressed and encoded version of the raw xml snippet . SAML compresses data using the Deflate method before base64 encoding it.

SAML Response Example

This is how the IdP responds when the user logs in.

ds:Signature: An XML Signature that protects the integrity of and authenticates the issuer of the assertion; the SAML assertion MAY be signed but doesn’t have to be. The example above contains two ds:Signature elements. The reason is that one is the message’s signature; the other is the Assertion’s signature
saml:Assertion: Contains information about the user’s identity and potentially other user attributes
saml:Subject: Specifies the principal that is the subject of all of the statements in the assertion
saml:StatusCode: A code representing the status of the activity carried out in response to the corresponding request
saml:Conditions: Specifies things like the time an Assertion is valid and that the Assertion is addressed to a particular Service Provider
saml:AuthnStatement: States that the IdP authenticated the Subject of the Assertion
saml:AttributeStatement: Contains Attributes that describe the Subject of the Assertion

Now that we’ve authenticated with the IdP and it has generated the SAML Response above, it responds to our authentication with another 302 redirect.

The 302 ultimately leads to us making a POST request to the Service Provider’s Assertion Consumer Service URL. The POST body contains the RelayState and SAMLResponse parameters. Recall that the ACS processes and validates the SAML Response.

Once the POST request is received, and the SAML Response is validated, we can access the protected resource we initially requested.

SAML Attacks

XML Signature Wrapping Attacks

When the Identity Provider sends the SAMLResponse to the service provider, the Service Provider needs to do two things:

verify the signature
get the information from the message

SAML Wrapping attacks are relying on the fact that step 2 may not be parsing the XML in the same way as step 1.

In these attacks the adversary modifies the message structure by injecting forged elements which do not invalidate the XML Signature. The goal of this alteration is to change the message in such a way that the application logic and the signature verification module use different parts of the message

XXE

Due to the fact that SAML Responses are deflated and base64’d XML documents, we can test for XXE by manipulating the XML document sent as the SAML Response. Example:

XLST via SAML

A Turing-complete language called Extensible Stylesheet Language Transformation (XSLT) is used to convert XML documents into other document types like HTML, JSON, or PDF. The fact that the attack can succeed without a valid signature is an essential point to remember. This is because the digital signature is not processed for verification until after the XSLT transformation. To execute the attack, we essentially require a signed SAML Response, although the signature can be self-signed or invalid. Example:

XML Signature Exclusion

Signature Exclusion is used to see how the SAML implementation works when no Signature element is present. The signature validation process could be completely bypassed if a Signature element is missing. Any content that would ordinarily be signed could potentially be altered by an attacker if the Signature isn’t validated.

Certificate Faking

A trusted Identity Provider signed the SAML message, and certificate faking is the process of determining whether or not the Service Provider validates this. Every time a SAML message is received, the trust relationship between the SP and IdP should be verified. What this refers to is signing the SAML Response or Assertion with a self-signed certificate.

Remediation

Depending on how each SAML implementation handles these vulnerabilities, remediation or prevention may differ. In general, the application should always carefully verify signatures, handle any user inputs that may be included, and finally, the identity provider and the service provider should be processing the responses in the same way to prevent these attacks.