Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Error on 'exp' type handling in ID Token #57
Thank you for your prompt reply.
In my PoC, ‘set_default_scopes’ function is called with ‘profile/email’ parameters as follows;
After I received a token, it contains ID token in forms of JWT.
Currently, it occurred about type handling issue of ‘exp’ in JWT.
In addition to the above reproducible case, it happens when either 'profile' or 'email' is specified on 'set_default_scopes' function.
After the execution, authentication server returns 'ID token' in forms of JWT (JSON Web Token), that contains an 'exp' element as integers, not a string (see RFC7519).
Before applying this patch, it cannot parse the 'exp' element in JWT properly.
Please check again.
*From: *Seong-Joong Kim <email@example.com> *Date: *Mon, May 6, 2019 at 10:31 PM *To: *google/google-api-cpp-client *Cc: *Subscribed @SurferJeffAtGoogle <https://github.com/SurferJeffAtGoogle>
What do you think of it as security issue? I think that it can be used for denial of service attack. *Description* An exploitable unhandled exception vulnerability exists during Google Sign-In with ‘google-api-cpp-client’. On an OAuth2.0 client, ID token handling can cause an unhandled exception resulting in denial of service.
Once a 3rd party service uses Google Sign-in with ‘google-api-cpp-client’,
a malicious user can trigger this vulnerability by requesting the client to receive the user’s ID token from an Google's authentication server.
If the user can retrieve tokens for themselves, that is a less severe problem. Any application or web page can be exploited by the user to expose their own authentication tokens. An exploit would allow one to retrieve the tokens for an arbitrary other user. *Attack vector*
If a 3rd party service uses Google Sign-In with an app or site via ‘google-api-cpp-client’, malicious user can make Google’s authentication server send the user’s ID token to the client on 3rd party.
Do you have an example exploit?
During type handling in ID token, it can cause an unhandled exception resulting in denial of service on 3rd party service. After then other users can no longer login/sign-in to the 3rd party service.
This library has no exception handling, so that is sort of a moot point. If it crashes, that is fine. If a service wants to enable exceptions, it could, but it should wrap calls to the library. *Vulnerability type*…
CWE-754: Improper Check for Unusual or Exceptional Conditions Sincerely, — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#57 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXHHHDAPGB2LNICXWBRVJTPUDSWLANCNFSM4FO5WXDQ> .
Thank you for your reply.
I am not talking about flaws of token exposure.
Similarly, there exist several vulnerabilities related to wrong type handling in client libraries.