Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JWK parsing does not tolerate leading whitespace #29086

Closed
ayoho opened this issue Jul 16, 2024 · 0 comments · Fixed by #29088
Closed

JWK parsing does not tolerate leading whitespace #29086

ayoho opened this issue Jul 16, 2024 · 0 comments · Fixed by #29088
Labels
release bug This bug is present in a released version of Open Liberty release:24008 team:Security SSO

Comments

@ayoho
Copy link
Member

ayoho commented Jul 16, 2024

Describe the bug
The JwKRetriver code used for parsing JWKS documents cannot tolerate strings that have leading whitespace.

Failing (current) behavior:

[7/16/24, 11:00:18:519 CDT] 00000058 id=79637d53 com.ibm.ws.security.common.jwk.impl.JwKRetriever             < getHTTPRequestAsString Exit  
                                                                                                                {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"iOghr5uyZ7zaYKsn3Qxu", ... }]}
...
[7/16/24, 11:00:18:519 CDT] 00000058 id=79637d53 com.ibm.ws.security.common.jwk.impl.JwKRetriever             > parseJsonObject Entry  
                                                                                                               <sensitive java.lang.String@7189f90a>
[7/16/24, 11:00:18:522 CDT] 00000058 id=00000000 com.ibm.ws.security.common.jwk.impl.JwKRetriever             3 Caught exception parsing JSON string [�쬒ܑH��@�n��"�H���!���g��`�'�njX�Knz��{OW��G.d:Qm��V%�V��w�wl�&`��Y��iyF1��������@����*�}&��*���X��0��ޓ�F���C�<����B��+1���ImRj���.&���^;@�����
��E2�\?�97�CӗF�{1}����ZY^I��!��_�`��2����0�y����AE;�Ck5���$A�d��e�����?I��[�������yy��;��\C�P���M����\�V�gkP�Y$�Wl�e�f��D�J� 3�~'Hق�u�&U�3�$�$R������zȠ�'[�+�;�Q�C%�<���ږ�R۞�����h󡡮������y��)`��-�ItpS�q�
��>�"�X�҄�a��������b2(��CM��^_dm��B��S���h\D�6������i���B�o�ION�R�{�^��2t�t�c� Y���\��]����vA���+5$S��d��Y�i;yE%TQ��S���E�LQ�L^P"�$�B���`U��k1��8�`�
����NA�qs�.f�@��ZD���G�1T��=
�h�4�����䙬�W�Y1�Т� �Jr�/4������h8���u�]: java.io.IOException: Unexpected character '�' on line 1, column 1
[7/16/24, 11:00:18:522 CDT] 00000058 id=79637d53 com.ibm.ws.security.common.jwk.impl.JwKRetriever             < parseJsonObject Exit  
                                                                                                               null

Expected (correct) behavior:

[7/16/24, 11:37:57:539 CDT] 00000066 id=25d137d4 com.ibm.ws.security.common.jwk.impl.JwKRetriever             < getHTTPRequestAsString Exit  
                                                                                                               {"keys":[{"kty":"RSA","e":"AQAB","use":"sig","kid":"3LIaBZHsHnRp4GHZlIOL", ... }]}
...
[7/16/24, 11:37:57:539 CDT] 00000066 id=25d137d4 com.ibm.ws.security.common.jwk.impl.JwKRetriever             > parseJsonObject Entry  
                                                                                                               <sensitive java.lang.String@599e7efc>
[7/16/24, 11:37:57:540 CDT] 00000066 id=25d137d4 com.ibm.ws.security.common.jwk.impl.JwKRetriever             < parseJsonObject Exit  
                                                                                                               <sensitive com.ibm.json.java.JSONObject@6ff7177d>

Between the two examples, the only difference (aside from unique values in the JWK objects) is a single leading space character that I added to the JWK response in the failing scenario. The Liberty code doesn’t do any kind of trimming on the response back from the server. If the response doesn’t immediately start with a { character, we assume we need to Base64 decode the response. Decoding the response ends up producing the junk string that you see in the trace with the exception, and we fail to parse the result as JSON.

Steps to Reproduce

  • Configure an OpenID Connect client
  • Set the jwkEndpointUrl of the OIDC client to an endpoint that produces a valid JWKS document, but with some kind of leading whitespace
  • Go through a standard login flow

Expected behavior
The Liberty server should trim the JWKS document for leading and trailing whitespace and correctly parse the JSON document.

Diagnostic information:

  • OpenLiberty Version: All releases since 18.0.0.3
  • Affected feature(s):
    • jwt-1.0
    • mpJwt-1.x, mpJwt-2.x
    • openidConnectClient-1.0
    • socialLogin-1.0
  • Java Version: Any
  • server.xml configuration (WITHOUT sensitive information like passwords)
    <openidConnectClient id="myLibertyOidcClient" jwkEndpointUrl="http://localhost:8010/oidc/endpoint/OidcConfigSample/jwk" ... />
@ayoho ayoho added team:Security SSO release bug This bug is present in a released version of Open Liberty labels Jul 16, 2024
ayoho added a commit to ayoho/open-liberty that referenced this issue Jul 16, 2024
@ayoho ayoho moved this to Done in Security SSO Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release bug This bug is present in a released version of Open Liberty release:24008 team:Security SSO
Projects
Status: Done
2 participants