Direkt zum Hauptbereich

On the Security of SAML-based Identity Providers

In previous posts we described Single Sign-On (SSO) and the messages within the authentication flow in detail. Additionally, we showed implementation pitfalls on the Service Provider (SP) side resulting in critical vulnerabilities.
In 2012 we started a study about the security of SAML based Identity Provider (IdP). The motivation to make this study was very simple – if the Identity Provider is vulnerable, all Service Providers are affected. In other words – even if the Service Provider is implemented correctly, an attacker can successfully get illegitimate access to restricted resources, e.g. victim's account.


At the beginning of the SSO protocol, the Service Provider redirects an unauthenticated user to the Identity Provider. With this redirect a Token Request is sent by the SP to the IdP (through the user agent, e.g. a web browser) in order to trigger the user authentication. The Token Request usually does not contain any sensitive information and thus is not encrypted or protected by a signature.

SAML Token Request
A Token Request usually contains the following parameters:
  • ID: A nonce, which guarantees that the Token Request was freshly generated.
  • IssueInstant: A timestamp.
  • AssertionConsumerServiceURL (ACSUrl): A URL pointing to the SAML interface of the SP, to where the IdP sends the authentication token.
  • Version: SAML Version.
  • Issuer: The identity of the SP.
By analyzing this parameters and in conjunction with previous research work [Gross], we discovered how critical the parameter AssertionConsumerServiceURL could be.

ACSSpoofing Attack
Requirements: The attacker sets up his own domain (www.attacker.com) and controls the incoming and outgoing messages to this domain. Additionally, the attacker is able to lure the victim to visit his domain. This can be done by posting a malicious link in web forums or sending it via email.
Out-of-scope: The attacker does not control the communication between Client and Service Provider. Thus, he cannot eavesdrop or manipulate this communication (i.e. no man-in-the-middle attack necessary).
The ACS Spoofing Attack protocol flow:
Figure 1: ACS Spoofing Attack: Protocol Flow
  1. Step 1: The user visits the domain controlled by the attacker, e.g. www.attacker.com
  2. Step 2: The attacker generates a TokenRequest containing a malicious ACSUrl and redirects the user to the IdP. The ACSUrl is a URL e.g. www.attacker.com.
  3. Step 3: The user is redirected to the IdP.
  4. Step 4: The user authenticates to the IdP. If the user is already authenticated, this step is skipped.
  5. Step 5: The authentication token containing the identity of the user is generated.
  6. Step 6: The authentication token will be sent to the domain specified in ACSUrl, which is controlled by the attacker – www.attacker.com.
  7. Step 7: The attacker redeems the stolen authentication token and authenticates on the SP as the user.
  8. Step 8: The attacker gets restricted resources controlled by the user.

The exploit:
Figure 2: ACSSpoofing Attack: Exploit Example
Figure 2 shows an exploit of the ACSSpoofing attack. On the left side you can see the encoded Token Request. According to the standard the Token Request is deflated and base64-encoded. On the right side you see the Token Request in XML format before deflating and base64-encoding.
The ACSSpoofing attack will be executed if a normal user clicks on the link in the left window.

Specification vs. Implementation flaw:
ACS Spoofing is an implementation flaw on the IdP-side. The SAML specification[http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf, Page .49] clearly specifies that the IdP MUST verify the ACSUrl. The verification of the received ACSUrl can be done via the data exchanged during the “Trust establishment” phase, see http://web-in-security.blogspot.de/2014/10/single-sign-on.html#more, section “The SSO protocol flow”.
  • ACSScanner: We implemented a tool able to analyze IdPs against ACSSpoofing. You can find the tool here: http://ssoattacks.org/acsscanner/
  • SAML EnDecoder: A very good and reliable tool to encode SAML messages can be found here: http://www.john-james-andersen.com/blog/programming/great-saml-decodeencode-tool.html
We have selected six real-world SSO IdPs that are available as a Software-as-a-Service (SaaS), do not require installation, and configuration is done on the client’s side. The selected IdPs are widespread and are used by enterprises.
According to our evaluation 4 out of 6 (~67%) IdPs were vulnerable against ACSSpoofing, which is a surprisingly high percentage.


According to the responsible disclosure model, we promptly reported our findings: CVE-2012-4962, -4963,CVE-2013-0114,CVE-2012-4961,CVE-2013-0115, -0116, -0117. Additionally, we supported some of the security teams by fixing the found flaws. As a result, some of them acknowledged our work : https://www.onelogin.com/whitehat

Authors of this Post

Vladislav Mladenov
Andreas Mayer

Beliebte Posts aus diesem Blog

Printer Security

Printers belong arguably to the most common devices we use. They are available in every household, office, company, governmental, medical, or education institution.
From a security point of view, these machines are quite interesting since they are located in internal networks and have direct access to sensitive information like confidential reports, contracts or patient recipes.

TL;DR: In this blog post we give an overview of attack scenarios based on network printers, and show the possibilities of an attacker who has access to a vulnerable printer. We present our evaluation of 20 different printer models and show that each of these is vulnerable to multiple attacks. We release an open-source tool that supported our analysis: PRinter Exploitation Toolkit (PRET) https://github.com/RUB-NDS/PRET Full results are available in the master thesis of Jens Müller and our paper. Furthermore, we have set up a wiki (http://hacking-printers.net/) to share knowledge on printer (in)security.
The hi…

Gridcoin - The Good

In this post we will take an in depth look at the cryptocurrency Gridcoin, we show how we found two critical design vulnerabilities and how we fixed them. In the last past years we saw many scientific publications about cryptocurrencies. Some focused on theoretical parts [Source] and some on practical attacks against specific well-known cryptocurrencies, like Bitcoin [Source]. But in general there is a lack of practical research against alternative coins. Or did you know that there are currently over 830 currencies listed online? So we asked ourselves how secure are these currencies, and if they are not just re-branded forks of the Bitcoin source code? Background Gridcoin is an Altcoin, which is in active development since 2013. It claims to provide a high sustainability, as it has very low energy requirements in comparison to Bitcoin. It rewards users for contributing computation power to scientific projects, published on the BOINC project platform. Although Gridcoin is…

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT