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

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

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

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…