SAML

Security Assertion Markup Language (SAML) enables SSO(Single Sign On) for Service Provider(SP) by using Identity Provider(Identity Provider) to authenticate to multiple services using single credential.

This is a legacy protocol which utilizes XML in SAML requests & responses, improper utilization of XML itself will lead to lot of vulnerabilities like XXE, Hence usage of SAML is highly not recommended unless necessary. (Use OAUTH instead, which is easier to maintain & relatively safe)

Terms -

  1. User - User who want's to authenticate to a Client

  2. Service Provider - Client which requires authentication (Ex: ManageEngine Endpoint Central Server)

  3. Identity Provider - Server which authenticates user to access Service Providers (Ex:Okta)

  4. SAML Request - Authentication request generated by SP & redirected to IdP

  5. SAML Response - Authentication response generated by IdP & redirected to SP to login user based on SAML Assertions present in SAML response.

  6. SAML Assertion - SAML Assertion is a XML document present inside SAML response, these have information about user identity, authorization/roles, session expiry etc

Flow -

  1. User tries to access Service Provider

  2. As, SP doesn't know user, so sends redirect to IdP with SAML Request in query params

  3. Browser redirects to IdP with SAML Request in query params

  4. IdP parses SAML Request, authenticates user.

  5. IdP generates SAML Response

  6. IdP redirects to SP with SAML response in query params

  7. SP verifies SAML Response & signature, assertions & other user paroperties present in SAML Response

  8. If SAML Response is valid & has valid signature, User is logged in mostly based on NameID parameter present in SAML assertion.

Note: To verify signature, SP must have public key of IdP stored locally either as certificate or metadata.

SAML Request

AssertionConsumerServiceURL - Information to IdP regarding where SAML Response should be sent.

Destination - IdP's address where SAML Request is being sent to.

ID - To uniquely identify SAML Request, this should match with InResponseTo parameter in SAML Response in most of the cases.

ProtocolBinding - HTTP-Redirect or HTTP-POST are available options, where HTTP-Redirect is generally used.It specifies how should the SAML Response be sent to SP in a GET request or POST.

SAML Response

ds:Signature - XML Signature that protects the integrity of SAML assertions & messages, the SAML assertion or may not be signed. The example above contains two ds:Signature elements. First ds:Signature element is signamture for whole SAML Response message, while later is that of SAML assertion.

saml:Assertion - These have information regarding user principal, user attributes, roles, session expiry & other user related information.

saml:Subject - It's contains the principal subject of SAML Assertion, the user or unique identifier which is used for authentication.The value of NameID is generally used as unique identifier for authentication.

saml:StatusCode - Denotes whether authentication is successfull in IdP or not.

saml:Conditions - Specifies things like the time an Assertion is valid and that the Assertion is addressed to a particular Service Provider.

saml:AuthnStatement - Denotes that IdP authenticated the Subject of the Assertion.

saml:AttributeStatement - Has Attributes that describe the Subject of the Assertion.

XML Signature

XML Signature can be used to sign entire SAML Response message or particular XML tree like assertion.

Reference element's URI attribute denotes element whose signature is calculated. This URI attribute must match ID attribute of element to be signed. For ex, URI="#_e0acf8ced7e2cafc7c65b2c097842486e0838d76e0" in the SAML Response denotes it's signature for Assertion element with ID="_e0acf8ced7e2cafc7c65b2c097842486e0838d76e0".

CanonicalizationMethod specifies whether the whitespaces or comments should be normalized or not.

Transforms specifies how the XML document must be transformed & how the signature must be calculated. Three common transforms are Enveloped Signature, Enveloping Signature & Detached Signature.

Enveloped Signature - In this type, Signature element is wrapped inside the element for which signature is being calculated.

Enveloping Signature - In this type, Element for which signature needs to be calculated is wrapped inside the Signature element.

Detached Signature - In this type, neither the signature element wraps the element it signs, nor the element which needs to be signed wraps the signature, i.e signature element is detached from the element which needs to be signed.

DigestMethod - This specifies the hashing algorithm which needs to be used to calculate digest value of element which needs to be signed.

SignatureMethod - Defines the signature algorithm which needs to be used to calculate Signature of reference element.

KeyInfo - This contains public key/certificate which needs to be used to check if signature is valid, It's the public key of IdP, It's suggested to store public key of IdP locally in SP & validate signature instead of relying on KeyInfo.

XSW Attacks -

In XML Signature Wrapping(XSW) attack, attacker modifies the XML document such that signature of the reference element/document is still valid, but due to application logic error in retrieving the referenced element, application actually retrieves the maliciously induced reference element rather than the original one.

XSW 1 Example -

In the above example, the attacker tries to wrap original Response element inside another evil Response element, Keeping the signature references of the original Response element intact, so that signature doesn't change. Attacker also adds his own Assertion element inside his own evil Response element.

When application tries to check for signature it will appear to be valid, but when it retrieves assertion element it retrieves evil Response element's Assertion instead of the original Assertion element.

There are 8 such XSW types, these are better explained at here.

You can use SAML Raider Burp Plugin to find all such XSW vulnerabilities easily.

Vulnerability Checklist

  1. Check for XXE & XSLT related vulnerabilities

  2. Check for DoS scenario by giving large amount of data in SAML Response for SP

  3. Check for XSW attacks, SAML Raider can be used to check for these attacks.

  4. Check for Signature Exclusion attack, by removing the signature. SAML Raider can be used to check for this attack.

  5. Check for Invalid Signature attack, by modifying content of reference element. May be application is checking for presence of Signature element instead of validating it properly.

  6. Check for Certificate Faking attack, If there is certificates present in SAML Response(KeyInfo) which is used for signature verification instead of locally stored IdP certificate, try to generate self signed certificate in KeyInfo & modify the contents of reference element & Sign the reference element using our own self signed certificate. You can use SAML Raider to perform this attack.

  7. Check for Token Recipient Confusion attack, Generate valid SAML Response for one SP, use the same SAML Response for some other SP.

  8. Check for comment injection attack 1, for example if user able to register in IdP admin<!--comment-->@idp.com, This will be parsed by SP as [email protected] depending upon canonicalization & logged in as [email protected] instead of admin<!--comment-->@idp.com.

  9. Check for replay attack after long time, to test is SP is properly validating saml:SubjectConfirmationData element's NotOnOrAfter attribute.

  10. Check if SP is regularly validating if currently logged in user is present in IdP or not. After login to SP, delete account in IdP, even after long time if you are logged in to SP, it's a session management issue.[Mozilla's Blog]

PreviousOAUTH 2.0NextJWT

Last updated