We’ve recently noticed a trend with a lot of New Zealand sites wanting to implement Single Sign-On (SSO) to combat the proliferation of passwords, including many government services. The most prevalent standard for doing this, providing interoperability between many vendors’ frameworks and multiple languages, is SAML 2.0. The usual mechanism for this passes the SAML response certifying the user’s identity through the web browser, using a signature to prevent tampering. Unfortunately, many SAML consumers don’t validate responses properly, allowing attacks up to and including full authentication bypass.
SAML 2.0 SSO
When signing in to a site with SAML 2.0, there are three parties involved – the Service Provider (‘SP’, the web application we want to access), the Principal (the user logging in) and the Identity Provider (‘IdP’, the authority). We want to accomplish the aim of getting the Identity Provider to tell the Service Provider, in a trustworthy way, who the Principal is.
We do this by having the Service Provider redirect our user to the Identity Provider with a SAML request. Once the Identity Provider is satisfied as to the user’s identity, they send them back to the Service Provider with a SAML response. There are three major ways of sending a message for web SSO, which the standard refers to as “bindings”:
- HTTP Redirect Binding. We include the SAML message directly in a URL.
- HTTP POST Binding. We include the SAML message in the body of a POST request.
- HTTP Artifact Binding. We send a random token, which acts as an identifier to retrieve the document via a back channel.
The first two of these can have some serious implementation issues.
Read the full article at: http://research.aurainfosec.io/bypassing-saml20-SSO/