SAML — What to check for?

SAML Validation and Pen testing.

This guide introduces the minimum requirements during validation and pen test of SAML implemented in your application.

TL;DR

Nowadays one of the most common ways of authentication is SAML (Security Assertion Markup Language). This is one of the ways in which we can implement Single Sign On into our applications. There are basically two parties involved in SAML. One is the Identity Provider (IdP) such as Okta, Microsoft SSO, DUO etc. The other one is Service Provider (SP), for example JIRA. The Identity Provider as the name suggests is the one responsible to authenticate the identity(user) requesting access. The Service Provider is the application for which an identity(user) wants access.

SAML Flow

a. Let’s say John Doe wants to use the application JIRA. He visits JIRA.

b. JIRA, the Service Provider (SP) creates the Authentication Request (an XML containing information such as issuer, recipient, how the authentication must be performed etc.) and sends it back to John Doe.

c. John Doe is redirected to Okta, the Identity Provider’s (IdP) website. If John Doe has no active session i.e. unauthenticated on IdP’s website , he is presented with IdP’s login page. (Okta login).

d. John Doe logs in using his IdP (okta) credentials and enters a 2FA code, if MFA is configured. If everything is fine, IdP creates a SAML Response (an XML with confirmation of John Doe’s identity), signs it, and sends it back to John Doe.

The IdP can send three types of XML messages known as assertions:

• Authentication Assertion: This provides proof that the user agent provided the proper credentials, identifies the identification method, and identifies the time the user agent logged on.
• Authorization Assertion: This indicates whether the user agent is authorized to access the requested service. If the message indicates access is denied, it indicates why.
• Attribute Assertion: Attributes can be any information about the user agent.

e. John Doe is redirected to JIRA again. JIRA (SP) verifies the signature and if John Doe has permission to log in to JIRA, he receives a JIRA session cookie.

What to look for

IF YOU ARE A PENTESTER

1. SAML response expiration: Check the message for timestamps, such as an IssueInstant or NotOnOrAfter assertion. The message is supposed to expire and become useless after that time. SP should not provide session token if expired SAML response is passed.
2. Message Replay: Assertions should contain a unique ID that is only accepted once by the application. Try replaying a SAML message to create multiple sessions.
3. Missing Signature: If there is a SignatureValue field present that contains a signature, try to resend the message without a signature.
4. Invalid Signature: Signatures which are not signed by a real CA are prone to cloning. Ensure the signature is signed by a real CA. If the certificate is self-signed, you may be able to clone the certificate or create your own self-signed certificate to replace it. Tool SAML Raider on burp.
5. SAML from Different Recipient: An application should only accept a SAML message intended for the SP application. The Recipient attribute found on the SubjectConfirmationData element is a URL that specifies the location to which the Assertion must be delivered. If the Recipient is a different Service Provider than the one who receives it, the Assertion should not be accepted.
6. Signature Wrapping: Some implementations check for a valid signature and match it to a valid assertion, but do not check for multiple assertions, multiple signatures, or behave differently depending on the order of assertions. The following are eight of the most common XML Signature Wrapping attacks. You can edit the original SAML file manually to perform these attacks but it is much quicker with the use of a tool. The short names (ex: XSW1) map to the names used in the SAML Raider tool, discussed below.

XSW1 — Applies to SAML Response messages. Add a cloned unsigned copy of the Response after the existing signature.

XSW2 — Applies to SAML Response messages. Add a cloned unsigned copy of the Response before the existing signature.

XSW3 — Applies to SAML Assertion messages. Add a cloned unsigned copy of the Assertion before the existing Assertion.

XSW4 — Applies to SAML Assertion messages. Add a cloned unsigned copy of the Assertion after the existing Assertion.

XSW5 — Applies to SAML Assertion messages. Change a value in the signed copy of the Assertion and add a copy of the original Assertion with the signature removed at the end of the SAML message.

XSW6 — Applies to SAML Assertion messages. Change a value in the signed copy of the Assertion and add a copy of the original Assertion with the signature removed after the original signature.

XSW7 — Applies to SAML Assertion messages. Add an “Extensions” block with a cloned unsigned assertion.

XSW8 — Applies to SAML Assertion messages. Add an “Object” block containing a copy of the original assertion with the signature removed.

1. XML Attacks: A SAML message is just a user-provided XML message that is processed by the Service Provider. Check against XML attacks, example lack of canonicalization which means logically same assertions but not textually same. This can be achieved by adding comments in between expected fields. XXE and XSLT attacks must be tested.
2. Change the expiration date on an expired message to make it valid again
3. Change the UserId to a different valid user — Bonus points if that user is an admin
4. Change the UserId to a different invalid user — Sometimes an application will grant default permissions or higher privileges to an unmapped user

For more in depth testing you may find resources at :

https://book.hacktricks.xyz/pentesting-web/saml-attacks

https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/

https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/

IF YOU ARE A DEVELOPER

Recommended — Use in-built libraries for SAML implementations. This will prevent manual validations and logic writing.

Before directly jumping to the security side of SAML Implementation. As a developer you need to be aware of the following details.

1. Understanding the role of Service Provider.
2. Understanding the SP- initiated SAML Flow or IdP initiated SAML flow.
3. Do you want to enable SAML for Single User or subset of users or everyone?
4. How to expose SAML configuration on SP.

Security in SAML

1. Only admin should have control over enabling- disabling the username password-based authentication or any changes to PII.
2. Session Timeouts must be enforced -set session expiry value to be the SAML Response NotOnOrAfter value. Set the session expiry value to logout time, when Forced session timeout occurs.
3. SAML must not be replay-able, maintain an ID token to verify against it. Check against the ID token to see if SAML is replayed.
4. Check the SAML response value against the IDP. If it is coming from the expected Identity Provider, before even checking the username.
5. Make sure the redirect is done to the expected page after SAML authentication. Use SAML RelayState parameter to check for this.
6. Validate the SAML signature using the IdP Cert provided in the SAML response. To make sure it is not tampered with.
7. Follow Secure XML guidelines provided by OWASP. SAML responses and assertions should be constructed using an appropriate XML library that can safely set user-controlled data in attributes and text nodes. XML Validation and XML Encoding must be in place. SAML Signature and their validation is the best way to detect tampering and prevent XML Attacks.

IdP Configuration

Entity ID: <EntityDescriptor entityID=”https://abcd.com /dashboard”>

1. Assertion Consumer Service (ACS) : URL where SAML Assertion is to be sent. https://abcd.com /saml/consume/
2. ACS Validator: Regex to validate if assertion is sent to correct ACS.

^https:\/\/abcd\.com\/saml\/consume\/$

1. Attributes: NameId Format and NameId attribute are minimum attributes requirement.
2. RelayState : Where to take the user after a successful login. https://abcd.com/dashboard/#
3. SAML Algorithm: SHA-256. Less commonly SHA-384 or SHA-512. This algorithm is used with the X.509 certificate.

SP Configuration

1. X.509 Certificate — A certificate provided by the IdP. It allows the SP to verify the SAML assertion is coming from the IdP it trusts. SAML assertions are usually signed, however SAML requests can also be signed. Download from IdP and paste it in SP.
2. Issuer URL — Unique identifier of the IdP. <saml: Issuer>https://okta.com/saml2/idp/metadata.php</saml: Issuer>
3. SAML SSO Endpoint — Service Provider Login URL.
4. SAML SLO (Single Log-out) Endpoint — An IdP endpoint that will close the user’s IdP session when redirected here by the SP, typically after the user clicks “Log out.” This will help logout users not only from SP but from IdP as well. https://okta.com/logout

References:

The above article is combined from various resources and sole purpose was to keep things at one place. Concise and precise.

Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them

SAML - what can go wrong? Security check - Securing

https://book.hacktricks.xyz/pentesting-web/saml-attacks

https://duo.com/blog/the-beer-drinkers-guide-to-saml