19

I've recently find out that by simple quick look into compiled code of one of our applications, you can get both App ID (API Key) and App Secret for Facebook API

I suppose that we should really keep App Secret (obviously from the word secret), so that nobody can access it, but what is the main threat related to leak of these items?

If the evil guy obtains these entries, what is the worst possible misuse he could perform?

Marek Sebera
  • 2,223
  • 3
  • 20
  • 27

2 Answers2

17

You are correct. App secret should be secret and should not be easily obtained by reverse engineering your client code.
Facebook uses OAuth so everything I say here also applies to all the applications that use OAuth to authorize and authenticate. The app secret authenticates your client to facebook. Just like a username/password authenticates a user to a webservice, mobile/desktop clients use app secret key as a credential for server to validate that its the 'real' legitimate client app.

If the evil guy obtains these entries, what is the worst possible misuse he could perform?

He could make a spoofed client that looks just like your client/application and release it. Unsuspecting users will download it and use it to connect to facebook. The fake app doesn't still get users credentials (which is good) because the authentication of user credentials happens on a facebook page. However, the user ends up authorizing this fake app on facebook. Facebook happily does that because it believes that anyone who presents that secret is you. As a result, the fake app gets the 'access token' for the user and can start posting comments and do other things that your real app doesn't intend to do.
So in a nutshell, its your reputational value that is at stake here. Other clients can impersonate as your client to facebook.

This is a thorough case study of one such twitter client which stored consumer key (their equivalent of app secret) in plain text.

I am quoting one line from that blog:

It’s very important to understand that a compromised consumer secret key doesn’t jeopardize the security of the users of the application. The key can’t be used to gain access to the accounts of other users, because accessing an individual account requires an access token that individual instances of the client application obtain automatically on behalf of the user during the authorization process.

Now, how do you protect the client secret?
If it is a standalone client (like a mobile app), you have little choice but to embed it in some form. Unfortunately for a expert reverse engineer, its only a matter of time before it can be decoded. After all its somewhere there (in some form) in the client. If the client can re-calculate/re-assemble it, so can a reverser.

Edit: If your application architecture permits it, your server can perform the OAuth steps on behalf of the client/mobile app. This way the key resides in the server, it does all the OAuth steps and passes the access_token to your client to use it to access user's facebook data. At this point you are doing something very similar to the browser - web server - facebook interaction described here. Just replace 'User's Browser' with your 'Client/Mobile App' and 'Your App' with 'Your Server' in that picture.

If this is some sort of a web application, this can be easily achieved by keep the key only on the server side and using facebook's server side flow to prevent app secret from leaking out.

Community
  • 1
CodeExpress
  • 2,422
  • 13
  • 10
  • 4
    *"you have little choice but to embed it in some form"* - Actually, you do have a choice. You can choose to not store the API secret in the client. Instead, the client/mobile app contacts your server. Your server then issues the request, and the API secret never leaves your server. This lets your server implement all suitable controls to prevent reputational damage to you (e.g., rate-limiting, checking that the action to be performed looks reasonable, etc.). – D.W. Sep 11 '12 at 06:59
  • 1
    @D.W. Yes, that is correct. In such a case the server is proxying on behalf of the client for the OAuth steps. This then becomes similar to the browser(client) - server - facebook model. I am editing my answer to include that. – CodeExpress Sep 11 '12 at 14:37
  • 2
    so then someone modifies the app and connect via your server anyway, like as if computers have proper security and facebook is ridiculous – Sam Watkins Jan 20 '13 at 17:57
  • 1
    @Shivam "If your application architecture permits it, your server can perform the OAuth steps on behalf of the client/mobile app"... This would I think only give you a way to shut down access to all (mobile/desktop) clients that use your proxy server. Should you detected evidence of abuse, it would mean shutting down access to legitimate applications as well since there would be no way to distinguish between them and the malicious ones. Great [link to the case study](http://arstechnica.com/security/2010/09/twitter-a-case-study-on-how-to-do-oauth-wrong/) btw - very nice article. – chrisjleu Dec 15 '14 at 13:51
5

In the case of Facebook — I don’t know about other OAuth-enabled sites — there is a possibility to use the anonymous aka application access token. It’s a token created by concatenating appId with appSecret, for instance 504216299598238|59d273f6dddb0a2f72e727132f4a74a4.

One could obtain this access token from the mobile app source and make authenticated requests to the Graph API. Then, Facebook provides some information about users that authorized this app earlier even without the user access token.

The attacker can gain access to confidential user data (email for example) this way. Here is a proof of concept:

This user has not authorized the application:

https://graph.facebook.com/100004668630549?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4

And this one did:

https://graph.facebook.com/100004619894646?fields=email&access_token=504216299598238|59d273f6dddb0a2f72e727132f4a74a4

The email field is otherwise not visible. Result: an attacker can obtain sensitive information about the attacked user without any interaction from that user.

Maciej Łebkowski
  • 151
  • 3