POSTS

Real-life OIDC Security (V): Redirect URI

This is the fifth post of a series on Single Sign-On and OpenID Connect 1.0 security. This post outlines how the vague specification of the Redirect URI within the OpenID Connect Core specification leads to real-life security issues. Finally, we show a real-world example of such an issue with CVE-2020-10776 (Keycloak) as an example.

The series consists of following posts:

  1. [Overview] Common Issue Patterns and Derived Security Considerations
  2. [Implementation] Login Confusion
  3. [Implementation] Injection of CRLF sequences
  4. [Implementation] SSRF issues in real-life OIDC implementations
  5. [Specification] Redirect URI Schemes
  6. [Specification] Reusable State parameter
  7. [Responsible Disclosure] Lessons learned during Responsible Disclosure of OIDC/OAuth related issues

As you can see, we structure the series in an [Overview], attacks with concrete examples categorized in [Implementation] and [Specification], and finally lessons learned during the [Responsible Disclosure]. Note that in this post the Redirect URI specification is analyzed and resulting behavior within implementations that follow this specification is outlined.

Acknowledgment

We made the observations within this advisory during the execution of my master’s thesis on “Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations”. The thesis was written at the chair for network and data security of Ruhr University Bochum.

The advisors of my thesis are Dr.-Ing. Christian Mainka (@CheariX), Dr.-Ing. Vladislav Mladenov (@v_mladenov) and Prof. Dr. Jörg Schwenk (@JoergSchwenk). Huge “Thank you” for your continuous support! 🙂

Introduction

The redirect_uri validation is crucial for the security of an OpenID Connect Identity Provider implementation. The OpenID Connect specification requires, that the provided value within the Authentication Request “[…] MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider” [1, Section 3.1.2.1.]. The comparison must be performed using “simple string comparison”. On the other hand, the specification is quite vague regarding the allowed schemes for redirect_uri values. Https should be used, but “The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application […]” [1, Section 3.1.2.1.].

In fact, if an Identity Provider follows these recommendations and does not restrict the request_uri regarding its scheme, a malicious Service Provider can choose redirect_uri values with an arbitrary scheme. This allows potentially dangerous schemes like javascript, vbscript, and data. If an implementation allows registering redirect_uris that use dangerous schemes, we consider this a security-relevant finding, because depending on the User Agent’s behavior, this can lead to Cross-Site-Scripting (XSS) vulnerabilities. Even if JavaScript is executed using a data URI, which results in script execution within the null origin, there are other potentially dangerous implications of the possibility to use arbitrary schemes:

  • Using data-URLs a malicious actor can execute JavaScript within the null origin. Besides the fact that the Same-Origin-Policy applies in this case, an attacker may be able to launch a Cross-Origin State Inference (COSI) attack. COSI attacks were, for example, shown by Sudhodanan et al. described in their paper “Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks” [2].
  • Additionally, using data-URLs a malicious actor may even target the End-Users PC by choosing a MIME type that the browser handles differently than common “web” MIME types. A recent example for this is Safari on macOS, which renders PostScript with the system’s rendering capabilities when encountering a data-URL with MIME type application/postscript: https://security.lauritz-holtmann.de/advisories/apple-postscript/
  • Outdated IE versions supported the vbscript scheme to execute VBScript. Microsoft disabled client-side VBScript in 2019 [3].
  • Recently quinn found an interesting vector that targets Firefox using the ws scheme), resulting in full-blown XSS [4].

Some of my test cases can be found here.

Example: Keycloak (CVE-2020-10776)

Keycloak is an open-source Identity and Access Management Software (IAM) maintained by Red Hat. In addition, Keycloak is used as the base for Red Hat’s Red Hat Single Sign-On.

Attacker Model

A malicious administrative user or a malicious Service Provider that registers using OpenID Connect Dynamic Client Registration are considered as attacker models in the following.

Description

According to the OpenID Connect specification, alternative schemes may be used as redirect_uri beside https. If the Client Type is configured as confidential, http is allowed as scheme. For native applications – e.g. the Twitter Application – even custom schemes like twitter:// may be used [1, Section 3.1.2.1.]:

REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). When using this flow, the Redirection URI SHOULD use the https scheme; however, it MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0, and provided the OP allows the use of http Redirection URIs in this case. The Redirection URI MAY use an alternate scheme, such as one that is intended to identify a callback into a native application.

Following the specification consequently, Keycloak does not restrict the scheme of the redirect_uri at all. This miss enables dangerous behavior, as the Authentication Response’s 302 redirect is sent to this URI with an arbitrary scheme. As a result, depending on the Browser’s behavior and treatment of the Location HTTP header, this may cause several security issues, potentially even leading to Cross-Site-Scripting (XSS).

Browser behavior regarding dangerous schemes in Location headers highly differs and changed in the last decade. Among a test-set of current and popular browser versions, only Safari 13.5 (iOS and macOS) executes JavaScript provided as data-URI, as shown in the following: Keycloak: JavaScript Execution using data-URL

The JavaScript execution is limited, as the script is executed in a different origin than the Identity Provider that sets the Location header (null origin). Thus, cross-origin access is restricted by the Same-Origin Policy. Nevertheless, an attacker may be able to launch a Cross-Origin State Inference (COSI) attack like Sudhodanan et al. pointed out in their paper “Cross-Origin State Inference (COSI) Attacks: Leaking Web Site States through XS-Leaks” [2] using a data-URL as redirect_uri.

Steps to reproduce

  1. Register a new client and configure the following redirect_uri: data:text/html,%3Cscript%3Ealert%281%29%3C%2Fscript%3E Keycloak: Client Configuration with data-URL as redirect_uri
  2. Visit the Authentication Endpoint of the created Client: https://keycloak.local:8443/auth/realms/master/protocol/openid-connect/auth?scope=openid&state=a&response_type=code&client_id=test&redirect_uri=data%3Atext%2Fhtml%2C%253Cscript%253Ealert%25281%2529%253C%252Fscript%253E&nonce=b
  3. After successful authentication there is a redirect to the registered redirect_uri:
HTTP/1.1 302 Found
Location: data:text/html,%3Cscript%3Ealert%281%29%3C%2Fscript%3E?state=a&session_state=b&code=c
[...]

Depending on the Browser’s behavior, the data-URI is parsed and the embedded JavaScript is executed. For instance, Safari 13.5 evaluates the provided Location header, as presented earlier.

Recommendation

For mitigating the above-described issue, potential dangerous schemes (e.g., javascript, data, vbscript) should be forbidden for redirect_uri values, as they open an unnecessary attack surface and there is, to our knowledge, no reasonable use-case for these schemes.

Responsible Disclosure

References

[1] https://openid.net/specs/openid-connect-core-1_0.html
[2] https://arxiv.org/abs/1908.02204
[3] https://blogs.windows.com/msedgedev/2019/08/02/update-disabling-vbscript-internet-explorer-windows-7-8/
[4] https://www.gremwell.com/firefox-xss-302

Thank you for reading this post! If you have any feedback, feel free to reach out via Mastodon, Twitter or LinkedIn. 👨‍💻

You can directly tweet about this post using this link. 🤓

Special thanks to Dr.-Ing. Christian Mainka (@CheariX), Dr.-Ing. Vladislav Mladenov (@v_mladenov) and Louis Jannett (@iphoneintosh) for your feedback on this post prior to publication! 🙂