0

I have a python script which writes data into a public google sheets file and for using the google sheets API I need to have a user authorize my script. I want to share the script with others and thus I'm considering sharing the client_secret.json as well, but I'm struggling at understanding the security-risks involved in this.

As far as I understand OAuth2, by providing client_secret.json my script authenticates itself and then a user authorizes the script to write data on the user's behalf, right?

Thus, am I correct, that the worst thing which could happen when I would share the client_secret.json, is that someone would exploit my service to write data into sheets (only his/her own or into public ones) by using my script's quota?

|improve this question
0

As user @thehowch stated and as I understand the whole procedure, the very main risk of sharing a client_secret.json is that of opening an attack vector for phishing attacks, since someone could just copy the client_secret and then present him/herself as a trustworthy authority where users would give their authorizations to it and thus would open their google drive to the attacker.

Also quota-usage of Google's API would be registered on the google project account which possesses the client_secret. Thus an attacker could just block our usage by exhausting the quota. Of course this risk is nothing compared to the phishing attack. Just as a side-node for the sake of completeness.

|improve this answer
  • There is a fairly nice guide to the different types of grant which are possible in OAuth2 at alexbilbie.com/guide-to-oauth-2-grants - I'm not sure which of these are available to Google API users though. Note that it would be fairly trivial to extract the client secret from any legitimate request (e.g. if they can run your copy, even with their own user credentials). – Matthew Jun 12 '18 at 10:49
0

The phishing attack is not possible to pull off because the authentication code is returned by the google server to a preauthorized redirect uri, which is controlled by the original app developer. So if your app only allows redirect to happen to 'redirect.yourapp.com' then it is impossible for a phisher to extract the code that the auth server returns after the user enters the password.

The only real damage an attacker can do with a client secret is a Denial-of-service attack by sending tons of fake auth requests to the OAuth server, resulting in a quota exceeded error or in being blocked.

I'd like to be corrected if I am wrong, but this is the only real problem I see with exposing client_secret.

|improve this answer
  • There is a vulnerability that I can think of.. which is an attacker sets up a website that looks like yours and then uses your client secret to fool a user into logging into dropbox or google thinking he is actually authorizing your app. However, the attacker would have to run his attack website on a different url and if the user is not able to notice the url is different, then he is hardly likely to notice a slightly different auth window as well. So such an attack does not need the client secret. – user1936097 Feb 24 '19 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.