Multiple Credentials Begone!

SAML is a standard for logging users into applications based on their sessions in another context. Most organizations already know the identity of users because they are logged in to their Active Directory domain or Intranet. It is only logical to use this information to log users in to other applications such as web-based application. This SSO login standard has two main advantages over authentication with more traditional methods like user name/password. 1. No need to type in credentials 2. No need to remember and renew passwords (Onelogin, 2016).

SAML SSO works by transferring the user’s identity from one place, the identity provider (IP), to another, the service provider (SP). This is done through an exchange of digitally signed XML (eXtensible Mark-up Language) documents. If the IP is the company’s Active Directory and the user authenticated against the AD when he sat down to work then his identity is already verified and known by the IP. Now if the user wants to log in to another web application, maybe an accounting app or the company’s ERP, once he accesses the app, this app will redirect the user back to the IP and ask for authentication. In this case, the user is already authenticated and there is no need to type in credential, so the IP builds and sends the response in form of an XML document and signed with an X.509 certificate. Once the SP validates the authentication received in the response and it makes sure it has a valid signed certificate then the identity of the user is established and he is granted access to the web application (Onelogin, 2016).

This all works very well but one of the most common problems with this service is misconfiguration. Failing to correctly configure your SSO service will result in many vulnerabilities. Misconfiguration gives an attacker the possibility of tampering with the data being exchanged. If the attacker is able to place himself between all communications between the service provider and the identity provider he can then intercept and modify the SAML messages being exchanged however he sees fit.

The most common areas of SAML messages that are prone to tampering are signatures and assertions. The signature enforces the trust relationship between the IP and SP. The assertion instructs the SP on what trusted operations to perform, usually to grant access to the application as a certain user (Jensen, 2017).

The two most commonly seen attacks in SAML are XML wrapping attacks and replaying attacks.

XML wrapping consist in wrapping or encapsulating a malicious payload within a SAML message without invalidating the original message. This is seen in SAML as XML assertion and signature wrapping, where the concept remains the same and the payload is added as a malicious assertion or signature. Since this doesn’t modify the original assertion’s or signature’s body, the message will still be valid.

Remember the SAML message is just an XML document and is full of tags. One of the tags is the signature or assertion the system needs. The getElementsByTagName() method returns a list of all the selected XML elements in the document. We focus on this method because it is the most popular amongst developers, probably because of its simplicity. .SamlConfig.Java

Doing this, the developer is making a very dangerous assumption, that the needed tag is the first and only tag. This assumption is what the attacker exploits by encapsulating a malicious assertion before the original one, hence becoming the item 0.

To solve this problem we have something called secure validation of SAML assertions. This consist of two steps. 1. Parsing the XML document and validating the structure based on a provided schema 2. Digital signature validation, which verifies authenticity and integrity.

The first step helps prevent wrapping. The second prevents forgery. (Krawczyk, 2012)

A replaying attack consist in replaying expired messages or resending the messages to another application. This is done with the intention of gaining valuable information or even replaying sessions and taking control.

SAML provides protection from replay attacks by requiring the use of SSL encryption when transmitting assertions and messages specifically to prevent interception of assertions. SAML also has artifacts. Artifacts eliminate the browser from the middle of the message exchange. This way sensitive data can be hidden from the end user or attackers between the site and the end user. With the correct configuration the SAML source site will only return the assertion to the requester to which the artifact was sent.

In the end it all comes to proper configuration. To take advantage of all the security measures that SAML has, proper and complete configuration must be set up. It’s like taking apart a desk and when you put it back together if you have screws leftover, you know it’s definitely coming apart, that desk is breaking, maybe not immediately but definitely at sometime. The same with SAML you can’t have any screws left over when you configure the service.