Is there a way to prevent someone from making his own client app for my webservice? [duplicate]

Question

Say I have a RESTful web service and a commercial Android app on the front end which is used to interact with it. I may use SSL so that the endpoints are not visible, but someone could still do some reverse engineering to find them.

I could also use SOAP instead, so that the call to the web service is a bit more complicated. But, I still don't know if this gives me any real advantage over RESTful based service.

I was thinking about hardcoding the key into my client app, so that only my client app could use the service. Also, maybe some code obfuscation may help. But, how much does this really help?

UPDATE: As JOW pointed out Fiddler

could be used to decrypt https and see the full request. However, if I use Android app only, this may be solved by hardcoding server certificate in Android client app. And also, there is SOAP WS-Security, but I guess a tool can be made to function in similar way as fidler to circumvent that.

Answer 1

This would be impossible. It is fundamental for your app to contain all the instructions necessary to use your API. Anyone with enough skill and time will be able to extract these secrets and create their own client.

Answer 2

It’s pretty easy and straightforward to create one’s own client regardless of whether REST or SOAP is used, as long as your Existing Client is available for everyone in the Play Store. Just capture the HTTP traffic from an Android device using Fiddler, and engineer your own client based on the captured traffic.

Even HTTPS traffic can be easily decrypted using Fiddler. The HTTP Methods, URLs, Headers, Cookies, Body and your Key are all visible. I don’t think this is secure at all. (There are other reverse proxies out there that can do the same as Fiddler.)

Answer 3

From a security perspective, no, there's no way to do this. No matter how much obfuscation you put on the code and protocols, the fact is that the code to access the API and the network traffic produced when the API is accessed is in the hands of your users, and they can use whatever reverse-engineering tools they want on it.

From a business perspective, you need to evaluate the cost to you if someone produces an alternative client against the extra cost to implement measures to prevent that from happening. For example, you could use a heavily-obfuscated proprietary API (avoiding REST, SOAP, and other standardised protocols) entirely, but this will be more difficult for you to implement and therefore cost more. On the other hand, it would make it considerably more difficult for someone to reverse-engineer. You need to work out if such measures (or other appropriate measures) are worth it to your business.

From a legal perspective, a lot of places have terms of service that prohibit the production or use of third-party clients. It's up to you to enforce that by monitoring traffic to your server to determine if one is likely to be using a third-party client, or by watching for the appearance of third-party clients on app stores. It's also up to you to decide if you have the resources to take legal action, and if it's worthwhile for you to take such action.

From a user-relations perspective, you may want to reconsider the idea of prohibiting all third-party clients as a blanket rule. Obviously nobody wants a developer to produce a horrible client with their own advertising, but a lot of services these days allow third-party developers to register their applications and receive an API key. The process of registering can be as simple or as complex as you want, ranging from a simple terms of use (e.g. "don't put your own adverts in the app") to an evaluation of their interface or a full examination of their source code (of course, the simpler it is, the more willing developers are going to be to sign up). Allowing third-party developers to use your API isn't necessarily a bad thing either - they might want to produce an app that uses your service as a data source but isn't related to it in any way, and in that case they could actually bring you more business if they put proper accreditation in their app, or they may want to fill a market that your business has no intention of going into, or they may truly have a better idea for a client app for your service, which is something you can learn from to improve your own app.

Answer 4

You can't make unauthorized access to the API impossible in the security sense, but you can minimize it. It's not really a security question but the concept of the threat model is pretty appropriate: Who do you want to prevent from accessing your API, and what kind of damage do you want to avoid?

Many large websites forbid alternative means of access to their service, usually so they can continue to serve ads. They do so through a combination of measures at many levels:

• checking the request headers and user agent (which stops great numbers of casual ordinary users)
• complicating the API by adding dynamic state, obfuscation and other measures (which stops casual reverse-engineering, but not the determined)
• forbidding it in their Terms of Service (which stops other legitimate businesses, and a few conscientious individuals)
• enforcing the ToS through lawyering (which may be necessary against unethical businesses, but will do more harm than good if deployed against small-scale individual users.)

None of these are 100% effective, but they don't need to be. The important thing is that they cut down on loss. Think about what you want to accomplish, and choose your countermeasures accordingly.

Answer 5

Say I have a RESTful web service and a commercial Android app on the front end which is used to interact with it. I may use SSL so that the endpoints are not visible, but someone could still do some reverse engineering to find them.

SSL does not conceal the target IP address, so they don't even need to reverse engineer anything. Everything else can be obtained via Fiddler + MITM certificate.

I could also use SOAP instead, so that the call to the web service is a bit more complicated. But, I still don't know if this gives me any real advantage over RESTful based service.

Well, the more effort you put in, the more effort a hacker will need to put in, I suppose.

That being said, hackers have a lot more free time than you, and there are a lot of them, and only one of them has to post the solution on a bulletin board and it's game over.

So, probably not worth the effort.

I was thinking about hardcoding the key into my client app, so that only my client app could use the service. Also, maybe some code obfuscation may help. But, how much does this really help?

Hackers now have deobfuscation tools at their fingertips, so it doesn't help as much as it used to.

Probably not worth the effort.

Fiddler could be used to decrypt https and see the full request. However, if I use Android app only, this may be solved by hardcoding server certificate in Android client app. And also, there is SOAP WS-Security, but I guess a tool can be made to function in similar way as fidler to circumvent that.

The hacker could reverse engineer all that much faster than you could build it.

So, probably not worth the effort.

You can't stop a hacker from reverse engineering any code that runs on the client. So whatever safeguards you put in, the hacker can imitate them.

Exactly. Don't spend time on this.

Instead, try to design your application so sensitive features are executed on the server, where you can protect it.

Spend the rest of your time improving the features of your app so customers won't want anything else.

Answer 6

You want to :

prevent someone from making his own client app for my webservice

You want your webservice to identify your app on user devices before further interactions, this seems impossible as you have no guarantee on the integrity of the app which could be altered with reverse engineering.

You may want to consider reviewing the architecture of your solution.

Answer 7

Yes, this can be done, though of course there are no perfect solution.

You would need to add encryption and message authentication to both client and server. Both negotiate a session key based on a shared secret, possibly with the addition of a unique client ID. There's plenty of documentation around on how to do that (keywords: session key, key exchange, API key). The key to this system is that the communication is encrypted and signed with the session keys, not with the actual key (aka shared secret). This way, the real key never travels the wire and cannot be intercepted.

An attacker could still reverse-engineer your client to extract the shared secret and the mechanism for deriving the session key from it. But this requires higher skills then simply listening to some REST chatter.

Answer 8

The only guaranteed why to stop unwanted usage is to perform some form of user authentication. Such as requiring the user of your app providing a username and password each time they start the app and passing this to the server. If the server validates the user it would return a session token that has to be used in all subsequent API calls. However, it might be that your application is not suited to making users login.

Without the login it will always be possible for someone with access to your API because they can reverse engineer your code and/or snoop the data to pass back and forth. So your aim is to make it as difficult as possible for someone to reverse engineer your code and API. Make sure you do not provide a fixed value from the client to the server. That is simple to find and then use in alternate client.

Instead you want to generate a new code each time you login to your server so that every time someone snoops the traffic they see a different value and they cannot simply replay that value. This forces them to reverse engineer your code to discover the algorithm used to generate the key. Put some effort into making that code hard to understand and so replicate.