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:
- [Overview] Common Issue Patterns and Derived Security Considerations
- [Implementation] Login Confusion
- [Implementation] Injection of CRLF sequences
- [Implementation] SSRF issues in real-life OIDC implementations
- [Specification] Redirect URI Schemes
- [Specification] Reusable State parameter
- [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.
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! 🙂
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 184.108.40.206.]. 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 220.127.116.11.].
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
data URI, which results in script execution within the null origin, there are other potentially dangerous implications of the possibility to use arbitrary schemes:
- 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 .
- Recently quinn found an interesting vector that targets Firefox using the ws scheme), resulting in full-blown XSS .
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.
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.
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 18.104.22.168.]:
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
data-URI, as shown in the following:
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”  using a
Steps to reproduce
- Register a new client and configure the following
- 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
- After successful authentication there is a redirect to the registered
HTTP/1.1 302 Found
Depending on the Browser’s behavior, the
Location header, as presented earlier.
For mitigating the above-described issue, potential dangerous schemes (e.g.,
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.
Thank you for reading this post! If you have any feedback, feel free to contact me on Twitter: @_lauritz_. 👨💻
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! 🙂