22

Let's say you have an app which uses OAuth so app can log in to the user's services (e.g. OneDrive, Google Drive, etc.)

Inside the app you have included the OAuth client secret (and client ID) as string constants.

An attacker extracts these from your app using reverse engineering techniques. What is the worst that the attacker can now do, knowing the OAuth client secret of your app?

Rumstall Fengleblunt
  • 221
  • 2
  • 3

3 Answers3

10

Sometimes you have to share the OAuth client secret, which is the case for mobile apps. The real protection here is the whitelist of where the OAuth secrets can be used. Despite the name "secret" sharing the OAuth client secret is generally not a problem for mobile apps - and is required to function.

The shared secret used in a 2-legged or 3-legged OAuth authentication flow might allow an attacker to initiate the SSO flow, and unwrap encrypted OAuth tokens. This may or may not be a problem, usually these tokens have a strict whitelist of where the SSO flow terminates, and the termination is the important part as this is where the access token is sent. An attacker might be able to use another vulnerability, such as an open redirect to subvert the SSO flow which is an OAuth RFC violation in it's own right. The combination of these two issues would result in an account takeover chained-exploit.

Try and avoid sharing secrets, and make sure that other protections in place. Consider reading the OAuth security best practices IETF document for all of the ways OAuth can go wrong.

rook
  • 46,916
  • 10
  • 92
  • 181
  • I don't think this answer is accurate. For the providers I've used leaked client secrets primarily appear to give the ability to impersonate the client asking for permission on the authentication screen. – udoprog May 16 '19 at 17:28
  • 2
    @udoprog you are correct, i didn't read the question carefully. Updated. – rook May 16 '19 at 18:32
5

In the authorisation code grant type, where client secrets are meant to stay secret, the user may tell the service that your application is authorised to access certain elements of their account. The important thing here is that they have authorised your application, not any other applications. The client secret is how you authenticate your application to the service.

Acquiring a client secret may allow a malicious application to impersonate your application, and any authorisation it has been granted. This might include replaying access and refresh tokens in order to access a user's account without their permission.

I do believe the attacker would usually need to acquire additional information (e.g. access tokens) in order for the client secret to be useful in practice (I'd love to hear about any scenarios where this would not be the case). Attacks wherein an existing user is lured onto a malicious page (with access to the client secret) may work in some contexts - although there may be complications around the referrer and the page the user is returned to.

The severity ('the worst it could do') would vary depending on the scope, but it's likely to have a negative impact on users of the application. In your examples of Google Drive and OneDrive, it might allow an attacker to read or modify a user's files, for instance, if that's the authorisation they gave.

Refs:

The implicit grant type is best for environments where a token cannot be kept secret (native desktop, native mobile, client-side browser, etc).

Community
  • 1
itscooper
  • 2,230
  • 13
  • 15
2

  1. Your API quota given to the 'Client ID/Secret' may be stollen by random 3rd party app. This could be problematic if you are using paid APIs.

  2. If the attacker obtained 'Client ID/Secret' and end user's 'Access Token' then the one can actually steal or damage end user's data. So, it's sorta like the abuser now has your ID. They need password to do worst things to end users.

Haebin Na
  • 21
  • 1