在iPhone应用程序中使用REST API时的安全性

Question

I know that this question has been asked in various forms before. However, I'm not looking for the "use https" answer. I'm already using HTTPS and I'm not worried about the sensitivity of the payload being transmitted back and forth.

However, an iPhone application that I am working on is talking to a REST API that I have built (I have control of the application and server - so any suggestions are welcome).

I use the OAuth2 protocol for authentication, which means that my "API key" is a combination of a Client ID and Client Secret that only need to be transmitted to acquire an access_token . After that, all requests are sent to the server using the access_token and a header containing an HMAC of the request body (using the client secret as a key). The only reason for this addition was so that someone couldn't make API requests with JUST an access_token .

The API that I'm talking to is going to be made public when I release the application. So I'm not necessarily worried about others being able to make API calls to it.

What I care about is:

• People being able to make API calls using my application's client credentials (which means that I can't detect on the server side that it didn't come from my application)
• People being able to abuse the additional scopes that my client ID will allow them to have, and traditional API users will not have

My guess is that there's not really a solution to this problem (other than using UIWebView and making a glorified webapp) but I thought I would ask around here anyway.

Can you all think of a way to protect the client ID/client secret if it needs to be consumed by the app?

Answer 1

I know this isn't the answer you were hoping for, but unfortunately I don't think you can accomplish your objectives with absolute assurance. At the end of the day, you can't trust a client which you don't control, and you don't control it once it leaves your hands.

In order to achieve your two objectives, you need to verify that the client accessing the API was written by you. The way to do this is using public/private keys pairs. You would need to embed a private key into the client that it can use to sign something. This way the server knows the request came from your client and not someone else's. This would also allow you to restrict certain calls to only your client.

However, this is not bullet-proof because a savvy user could reverse engineer and extract the private key from your app and use it to spoof the source. Although not bullet-proof, it is bullet resistant because doing that would require A LOT of work and would be highly technical, especially if you use anti-RE techniques like buffer smearing, mass red-herrings, etc.

If I were you, I would ask myself what type of damage would result if someone for sure hacked it. If you are Facebook it is catastrophic. If you are serving an internal organization it may not be a big deal at all. If you can't afford a single abuse, then you need to reconsider your design because this one isn't going to work. You simply cannot trust code that you don't control, and you don't control the client anymore once it's on someone else's device.