Security Analysis in an OpenID Connect Lab Environment

In this post, Christian Fries shows an approach to unveil security flaws in OpenID Connect Certified implementations with well-known attack methods. One goal of the master's thesis Security Analysis of Real-Life OpenID Connect Implementations was to provide a platform for developers and security researchers to test implementations in a reproducible and maintainable OIDC lab environment.

We included six OpenID Provider (OP) and eight Relying Party (RP) services in the lab environment. For the comprehensive security analysis, we tested the implementations against eleven Relying Party attacks and seven OpenID Provider attacks in different variations with our tool PrOfESSOS. In addition, we carried out manual tests as well. We have disclosed twelve implementation flaws and reported them to the developers in a responsible disclosure process.

Two developer teams fixed (✔) the vulnerabilities before the deadline of the master's thesis. One Redirect URI Manipulation vulnerability was rejected (✖). This particular case can be permissible for only one registered URI for reasons of interoperability and fault tolerance. We informed three further development teams (✦).

Name	Vulnerability	Fixed	CVE
MITREid Connect	PKCE Downgrade Attack	✦
mod auth openidc	ID Spoofing, JWKS Spoofing	✔
node oidc-provider	Redirect URI Manipulation	✖
OidcRP	Replay Attack	✦
phpOIDC	Message Flow Confusion, ID Spoofing, Key Confusion	✦
pyoidc	Replay Attack, Signature Manipulation, Token Recipient Confusion	✔	CVE-2020-26244

We explain the method of how we have archived this result in the following sections.

Security and Privacy of Social Logins (III): Privacy in Single Sign-On Protocols

 This post is the second out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.

Part II: PostMessage Security in Single Sign-On

It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

Part III: Privacy in Single Sign-On Protocols

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

• Introduction to XS-Leaks in Single Sign-On
• XS-Leaks in Single Sign-On: Account Leakage Attack
• XS-Leaks in Single Sign-On: Identity Leakage Attack
• Automatic Sign-In and Session Management Practices in the Wild

Security and Privacy of Social Logins (II): PostMessage Security in Single Sign-On

This post is the second out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.

Part II: PostMessage Security in Single Sign-On

It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

• Vuln. 1) DOM-based XSS on myaccount.nytimes.com
• Vuln. 2) Account Takeover on cbsnews.com, cnet.com, and zdnet.com
• Vuln. 3) Account Takeover in SAP Customer Data Cloud (GIGYA)

Part III: Privacy in Single Sign-On Protocols (coming soon)

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

Security and Privacy of Social Logins (I): Single Sign-On Protocols in the Wild

This post is the first out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.

• Identity Provider: Apple
• Identity Provider: Google
• Identity Provider: Facebook

Part II: PostMessage Security in Single Sign-On

It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

Part III: Privacy in Single Sign-On Protocols (coming soon)

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations

This is a guest blogpost by Lauritz Holtmann. He wrote his master thesis:

"Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations"

Lauritz summarizes his exciting results in the following. The thesis was supervised by Vladislav Mladenov, Christian Mainka, and Jörg Schwenk. You can read find his full thesis here.

OpenID Connect 1.0 and OAuth 2.0 are the Single Sign-On Protocols that are implemented in modern web applications. In this post, we outline common issue patterns that were discovered in popular OpenID Connect implementations, give concrete examples of vulnerabilities, and give recommendations for adjustments to the OpenID Connect specification.

PKCE: What can(not) be protected

This post is about PKCE [RFC7636], a protection mechanism for OAuth and OpenIDConnect designed for public clients to detect the authorization code interception attack.

At the beginning of our research, we wrongly believed that PKCE protects mobile and native apps from the so called „App Impersonation“ attacks. Considering our ideas and after a short discussion with the authors of the PKCE specification, we found out that PKCE does not address this issue.

In other words, the protection of PKCE can be bypassed on public clients (mobile and native apps) by using a maliciously acting app.