Certification: Proposed change to how invalid redirect urls are tested

[Joseph Heenan]

After the presentation “OAuth 2.0 Redirect URI Validation Falls Short, Literally” given by Tommaso Innocenti at OSW, I thought it would be interesting to revisit how we test redirect uri validation in the certification tests.

In particular this slide shows some attacks that have been possible due to servers accepting redirect urls that are the registered redirect url with extra things added on the end:

If we look at a recent certification result (picked at random):

https://www.certification.openid.net/log-detail.html?log=0wpf6WXzKChcLyq&public=true

We expected the client to have this redirect url registered:

https://www.certification.openid.net/test/a/JustPassMe/callback

And we expect this redirect url to fail:

https://www.certification.openid.net/test/a/JustPassMe/39Y8nOAX3K

So that we could detect the problematic validation, we could change the unregistered redirect url the test tries to:

https://www.certification.openid.net/test/a/JustPassMe/callback/39Y8nOAX3K

However I thought it was best to check with the working group that this seemed a sensible course of action before we did it.

The standards are quite clear here an exact simple string match is needed, so I think from that point of view we’re good to do this. I think there are deployments in the wild that deliberately allow some kind of wildcard or additions to redirect urls and this might result in such a system failing conformance. (I overheard a hallway conversation where one implementation allowed a tenant id to be added to the redirect url path as the only alternative they currently had was registering 1000s of redirect urls).

‌

There is also a related blog post at https://security.lauritz-holtmann.de/post/sso-security-redirect-uri-ii/ but I’ve not yet worked out a concrete action that would make sense for that one as I think any testing would require registering a redirect url that has a ‘code’ parameter in it and I’m not sure there’s any clear requirement in any specification/RFC as to how such a url would be handled.

[Michael Jones]

We discussed this on the 2-Oct-23 working group call. We certainly encourage the certification suite to take steps to prevent certified implementations from being vulnerable to these attacks.

[Andrii Deinega]

The OpenID Connect Core 1.0 has something to say about it

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).

This exact match also “covers” the URL path. So, definitely, this attack against implementations.

However, the OpenID Connect Core specification may put some restrictions on what is allowed, and what isn’t allowed to have in redirect_uri. As of now, https://openid.net/specs/openid-connect-core-1_0-32.html#QuerySerialization seems like says only

In order to serialize the parameters using the Query String Serialization, the Client constructs the string by adding the parameters and values to the query component of a URL using the application/x-www-form-urlencoded format as defined by [W3C.REC‑html401‑19991224]. Query String Serialization is typically used in HTTP GET requests. The same serialization method is also used when adding parameters to the fragment component of a URL.

The URL path of redirect_uri should be properly URL encoded in order to avoid such attacks. Furthermore, it might make sense to specify what should happen with non english characters in redirect_uri. I mean in its path and its domain (internationalized domain names).

‌

[Joseph Heenan]

@Andrii If you think it’s underspecified it might be best to raise a separate issue to be considered for the spec errata.

It’s not something I’ve heard causing difficulties, though I can’t tell you whether or not it’s clear how it should be done.

[Joseph Heenan]

Thanks for the working group answer Mike! I’ve opened a ticket to make this change in the conformance suite:

https://gitlab.com/openid/conformance-suite/-/issues/1246

We not received any objections and I don’t need anything more from the working group, so I’ll close this issue.