Contents
- What is SAML?
- SAML Work Flow
- SAML Assertion
- SSO Request and Response
- SSO Security Testing Guidelines
- Conclusion
What is SAML?
SAML the Security Assertion Markup Language was created by an organization known as OASIS. Nowadays applications make use of the latest version of SAML 2.0. SAML was developed to remember multiple passwords for various applications of an organization, which would help the employee. Because no one is gonna remember multiple passwords or they will have the same password for all the applications lol!!!
SAML uses XML based data format or protocol for exchanging data between identity provider and Service provider. Thus it uses XML to facilitate identity checks.
SAML Work Flow
SAML is used to facilitate Authentication mechanism from user’s browser to the application server. This is done by Single Sign On (SSO) feature. When it comes to SSO, SAML defines three parties which are directly involving in the communication flow, they are
- The Principal (User)
- The Identity Provider (IDP)
- The Service Provider (SP)
The Principal (User): It is the actual application user which would try to authenticate to the application for accessing some resources.
The Identity Provider (IDP): As the name indicates, identity provider is a key component of SAML authentication process. It has two major tasks. First, it is responsible for authenticating the users by validating their login credentials, hence it acts as an authentication and authorization authority. Second most important task is that the IdP should issue assertions for the SP which are relevant to the user authentication result.
The Service Provider (SP): It is the actual service or the application that the user is trying to access, for example Facebook. Service provider allows users to access its resources based on the assertions issued by the identity provider.
Below image explains the actual workflow of SAML (SSO) authentication.
SAML Assertion
SAML Assertion is a package of information which is related to authentication security provided by the identity provider.
There are 3 kinds of assertion statements defined in SAML 2.0 standard,
Authentication Statement: This statement provides information about a subject or principal (user) which will authenticate with the identity provider at a particular time using a particular method.
Attribute Statement: This statement is used to provide associated attributes with the subject for the use of relaying party. An attribute is simply a name-value pair and also there can be more supporting facts that describes the subject.
Authorization Decision Statement: This statement specifies authorized actions to be made by the subject on particular resources. It can be simply thought as granting or denying access to certain services or resources.
Single Sign On (SSO) Request and Response
SAML SSO authentication request is sent from the Service Provider (SP) to the Identity Provider (IDP). There are 2 examples of authentication request generated by the service provider
- An Auth Request with its Signature (HTTP-Redirect binding)
- An Auth Request with the signature Embedded (HTTP-POST binding)
Auth Request with its Signature
In this type of request, the signature value is binded to the request during the HTTP-Redirect. In addition to that, the XML auth request contains details like user’s ID, Service URL etc., which should be validated by the signature value at server side.
Auth Request with the Signature Embedded
In this type of request, the signature value is embedded within the XML auth request with other details like User’s ID, and service URL.
An Authentication Response is generated by the Identity provider. If the user’s credentials are valid and sent to the service provider, then it sends the response token to user’s browser.
There are 8 examples of Auth Response in SSO:
- An unsigned SAML Response with an unsigned Assertion
- An unsigned SAML Response with a signed Assertion
- A signed SAML Response with an unsigned Assertion
- A signed SAML Response with a signed Assertion
- An unsigned SAML Response with an encrypted Assertion
- An unsigned SAML Response with an encrypted signed Assertion
- A signed SAML Response with an encrypted Assertion
- A signed SAML Response with an encrypted signed Assertion
Click here To know More about Application & API Security Testing
Single Sign On (SSO) Security Testing Guidelines
While testing an application which has Single Sign On (SSO) enabled, it is necessary to verify and validate the SAML authentication response data to find out vulnerabilities.
- If an attacker can control the SAML response passed to the service provider, they can authenticate as someone else. While testing the SSO applications, it is essential to analyse the SAML authentication response from the application. Since the SAML response is used to relay authentication information to the service provider, there must be some fields that communicate that data. Security testers can look for key parameters in the XML auth response like User ID, username, email address and signature etc.,
Check the SAML Signature value: SAML (SSO) authentication uses signature (token) values to validate user sessions. Security tester has to verify if the signature is verified in server side or not. Below few security testing scenarios is been mentioned based on SAML signature present in auth response.
Need Support on Securing your Digital Assets?
1. Signature not present in XML response or Not verified
If the SAML response lacks a signature or if the signature of the SAML response is not verified, then the tester can remove the signature value, tamper with username or email parameter and authenticate to someone’s account.
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.
2. Signature value is verified only if it is present in XML request and response
Tester should verify, if an application allows user to access resources after removing the signature value from the XML request or response. Sometimes, it may be possible to authenticate without valid signature.
The goal is to forge a well formed SAML Assertion without signing it. For some default configurations, if the signature section is removed from a SAML response, then no signature verification is performed.
Below image shows,
- Tester login with user credentials,
- Get the XML response for authentication,
- Remove signature of the user and edit the SAML assertion parameter “Name” from his user to user “Admin” to login as admin user due to n signature validation.
3. Predictable Signature
Signature value should not be predictable, as it may allow attackers to brute force the values, and take over all user accounts.
4. XML External Entity (XXE) Injection
Since SAML (SSO) request and response are based on XML, it is possible to find out XML related input validation vulnerabilities like XML injection and XXE injection.
Click here To know More about Cloud Security Testing
Conclusion
SAML Single Sign On feature are widely used by a lot of organizations across the globe. SSO helps employees of an organization to carry out their task without scratching their head for multiple usernames and passwords for different applications of their day to day work. Even though SSO is considered to be secure, it may become vulnerable due to improper implementation mechanisms. This makes it easy for intruders to take down organisations as all their applications are centrally connected by SAML.
Briskinfosec recommends an apt solution to mitigate the risk of SAML and SSO based threats by carrying out Application security assessments on regular basis.
Keen to know about the Cyber Attacks that happened across the Globe