Non UTF-8 URL encoded issue with mod_auth_openidc

[cnico]

Hi,

We have spent quite some time to find what is the root cause we encounter with mod_auth_openidc usage.
Here is our use case : we use mod_auth_openidc for some apps with a keycloak server as our enterprise SSO solution.
It works very well but we found that in the following situation : with IE 11 and some of our service that have unicode characters in the URL, when we authenticate, there is a IE technical error that is displayed.
After activating mod_auth_oidc logs in debug, the analysis leads to the fact that once the authentication is done with keycloak, the redirect to the effective service does not work. More precisely : mod_auth_openidc sends a 302 redirect with no Location HTTP header...
Searching the root cause of this fact, I find that in the first request when mod_auth_openidc stores the original url before sending the redirect to keycloak, it actually stores nothing.
Here is the corresponding log :
[Mon Feb 14 11:18:13.764738 2022] [auth_openidc:debug] [pid 25289:tid 140009656821504] src/proto.c(563): [client 10.x.x.x:34824] oidc_proto_authorization_request: enter, issuer=https://xxxx/auth/realms/intranet, redirect_uri=http://xxxx/redirect_uri, state=tP1xxxxxx-0, proto_state={"om":"get","i":"https://xxxxx/auth/realms/intranet","rt":"code","n":"NuxxxxxI","t":1644833893}, code_challenge=(null), auth_request_params=(null), path_scope=(null)
There is no "ou" in the proto_state compared to a correctly working use case. Here is a working log :
[Mon Feb 14 11:21:13.894160 2022] [auth_openidc:debug] [pid 25289:tid 140009300166400] src/proto.c(563): [client 10.x.x.x:49685] oidc_proto_authorization_request: enter, issuer=https://xxxx/auth/realms/intranet, redirect_uri=http://xxxx:23980/redirect_uri, state=vMxxxxx4, proto_state={"ou":"http://xxxxxx/myservice?myparams=toto","om":"get","i":"https://xxxx:29681/auth/realms/intranet","rt":"code","n":"dxxxxJU","t":1644834073}, code_challenge=(null), auth_request_params=(null), path_scope=(null)

Having searched in the code, my analysis is that oidc_util_encode_json_object in util.c uses the jansson method json_dumps that ignores the non UTF-8 encoded string of the request_rec struct.

We corrected the problem by changing IE 11 advanced configuration to force url encoding of all characters and not use unicode in URL.
I think that mod_auth_openidc should have a small improvement here and detect such a situation where the service url can not be stored in json and at least logs an explicit ERROR about it.
A better approach could also be to encode and decode the service url before storing it in json if it contains unicode characters so that the user has no problem at all in such a situation.

I googled if it is possible to force chrome or firefox to not url encode the adress bar url and it seems there is an advanced option for it but I did not tested it.

I did not create an issue as it would have been directly closed and I let you decide what to do to improve this specific case.

Note : the version of mod_auth_openidc we use is the 2.3.10.1 but my analysis of the code is that the problem is the same in the most recent version.

Regards,

[zandbelt]

can you provide an example of a URL that fails?

[cnico]

Yes, here it is as logged in the apache logs :
[Mon Feb 14 11:18:13.764434 2022] [auth_openidc:debug] [pid 25289:tid 140009656821504] src/mod_auth_openidc.c(3763): [client 10.152.6.42:34824] oidc_check_user_id: incoming request: "/myService?param1=abc&param2=Code%20partenaire%20non%20trouv\xe9&param3=toto", ap_is_initial_req(r)=1

In the browser adress bar, it is displayed as :
http://xxxx/myService?param1=abc&param2=Code partenaire non trouvé&param3=toto

The 'é' character is correctly encoded in unicode with \xe9 value.
And If the url is encoded, in the logs, the é character is replaced by %C3%A9 and it works without problem.

[zandbelt]

when I try to reproduce I see the "ou" correctly stored in the proto state as follows:

[Mon Feb 28 19:39:07.687585 2022] [auth_openidc:debug] [pid 94116] src/mod_auth_openidc.c(3953): [client 127.0.0.1:58350] oidc_check_user_id: incoming request: "/protected/index.php?param1=abc&param2=Code%20partenaire%20non%20trouv\\xe9&param3=toto?param1=abc&param2=Code%20partenaire%20non%20trouv\\xe9&param3=toto", ap_is_initial_req(r)=1
...
[Mon Feb 28 19:39:07.688223 2022] [auth_openidc:debug] [pid 94116] src/proto.c(647): [client 127.0.0.1:58350] oidc_proto_authorization_request: enter, issuer=https://host.docker.internal:9031, redirect_uri=https://localhost.zmartzone.eu/protected/, state=j5yU2_UctEGugAVpem4I9iHar2w, proto_state={"ou":"https://localhost.zmartzone.eu/protected/index.php?param1=abc&param2=Code%20partenaire%20non%20trouv\\\\xe9&param3=toto","om":"get","i":"https://host.docker.internal:9031","rt":"code","n":"aYnIXTlBEpNr2RyQyJvXqs-wgyS3tm6DAicnbXGyYFw","t":1646073547}, code_challenge=(null), auth_request_params=(null), path_scope=(null)

i.e. it is not missing; can you paste the server debug log entries for IE 11?

[zandbelt]

ok, I was able to reproduce this now (using a printf/netcat client); it turns out that json_string doesn't handle the unencoded non-UTF-8 Unicode characters and returns NULL; a warning is added in d13ee0e

[cnico]

Well done.