How can you prevent arbitrary client apps from usi

问题:

Apologies if this has already been asked and answered; I've looked around a bunch but haven't found exactly what I'm asking.

--

1. Suppose my web app at http://example.com/ uses a private and undocumented web API at http://api.example.com/ to fetch data, e.g. via XHR or JSONP.

2. Also suppose that this web app is anonymous — it does not require user login.

3. Since there's communication between client and server, anyone can open Fiddler, etc. to see the exact request and response, not to mention inspect the client-side JS code.

In a case like this, how can you prevent someone from using your API in a non-web client app? E.g. an iPhone app, or server-side.

To my understanding, point #2 removes the option of something like OAuth, and point #3 removes the option of e.g. API keys or even SSL.

I've thought about things like time-based tokens or secret salts that are injected into the page on first load, but an iPhone app could easily just secretly load your webpage before making API requests.

So is there any way besides just plain obfuscation — security through obscurity?

--

In case all that is too abstract, here's a simple example:

Google.com fetches its auto-complete data via some API that's private and undocumented — but open on the web. What's to stop me from using it in my iPhone app?

回答1:

You can't prevent people from copying your client code or replaying network traffic.

Thanks to the same origin policy, other web apps can't access your API from the client. They will have to proxy their requests via the server, meaning these requests will come from a handful of easily identified IP addresses, which you can temporarily blacklist.

As for desktop and mobile apps, there's not much you can do. My advice is to not worry about them until they're a problem.

That said, it doesn't hurt to be prepared. If you want to avoid expensive legal battles, one thing you can do is change your API method signatures from time to time. Leaching apps can be fixed, but their reputation will steadily decline.

回答2:

Authentication doesn't prevent abuse of your API's either. As long as the client can correctly authenticate with your system, he can use any client he / she chooses. Only the case where the client and the server are both secure and the connection is secure can you avoid abuse.

If the problem is abuse, then a simple throttling solution may be adequate.

回答3:

Without an API key or some form of authorisation, you will be fighting a losing battle trying to keep unauthorised clients off your service.

You can sniff multiple things, but hard truth is most are easily forged.

Do you control the other web service? Also, if your web app (http://example.com/) accesses the API (http://api.example.com/) via XHR or JSONP, could you proxy the data on your server by using a library such as cURL to get the data, and then make it available on your site. You could then control the access to it any way you see fit.

回答4:

If your client has code that is hidden from snoopers, could you not do as you suggested, use salts, ip address and time based values, encrypt them and then do the same on the server end? This is basically what mod_auth_tkt does, and it works well. Or would that constitute authentication?