Error on 'exp' type handling in ID Token #57
Comments
|
Hi Seong-Joong. Thank you for reporting this issue. The code fix looks good too. I would like to try to reproduce the issue. Is there a simple way to reproduce it? |
|
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. |
|
Hi all, 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. Many thanks!! |
|
@SurferJeffAtGoogle Description Attack vector Vulnerability type Sincerely, |
|
*From: *Seong-Joong Kim <notifications@github.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. |
|
Thanks for filing the issue, but we deprecated this repository, so closing. |
Problem:
The following errors occurred during the attempt to request ID Token with specifying ‘profile’ or ‘email’ in SCOPES parameter.
Cause:
When receiving ID Token from Google OAuth Server, ‘exp’ in the token is representing the type of integer. Unfortunately, 'google-api-cpp-client' deals with it as a string type; it causes the above problem. For your information, I attached the format of ID Token received from the server.
The text was updated successfully, but these errors were encountered: