Is it possible to check a client side application identity from server side?

Question

Assume there is a web service which is visible publicly but it must be just responsive to a specific client application. Is there any mechanism to check client side application identity to prevent disallowed application to access the service?

For instance, I have a web service which is called by my iOS application. I want to prevent others from calling my web service.

Regarding the fact that others can decompile my client application and create another one which is working the same as mine, I think the only way to avoid unwanted access to the service is to check application identity on server to ensure the request comes from my own application.

Is there any robust and secure way to do that?

What you're probably looking for is "certificate-based client authentication." — Robert Harvey, Dec 02 '13 at 18:51
you hit upon a classic problem in gaming, hacked clients and how to prevent them access, best way is to not trust the client at all — ratchet freak, Dec 02 '13 at 19:48

score 5 · Answer 1 · answered Dec 02 '13 at 19:52

Security doesn't come from the client, but in how you implement your web service. Ensuring that you only accept transactions from your own client does little to improve security.

Safe web service operation requires that the service operate independently from the client, and that there are no service APIs that can cause harm to the service or other users of that service.

Authentication, session tracking and SSL are techniques that can improve security of a web service. I would focus on those efforts first before worrying about verifying the origins of a connected client. If your web service is secure then there should be no benefit to anyone who gains access to the source code of the client.

Think of your web service as a black box. The client can connect, issue requests and transactions but at no time does the client ever know what is going on inside the black box.

score 0 · Accepted Answer · answered Dec 02 '13 at 19:09

0

No. As you said, anyone can decompile and mimic your own client application. You can never trust input from a client if you do not trust the user of the client.

You can add additional safeguards to attempt to make it more difficult to create a new client. For example, if your client always uses services with a certain max frequency, then a client that connects and issues requests much faster than that may be a hacked client.

answered Dec 02 '13 at 19:09

Chris Pitman

3,426
1
18
21

Thanks, Is your "No" mathematically or practically (from software engineering point of view)? How about Code Signing or [Digital Signature](http://en.wikipedia.org/wiki/Digital_signature) that some folks have suggested [here](http://programmers.stackexchange.com/questions/219028/how-to-safeguard-a-rest-api-for-only-trusted-mobile-applications)? I am not such professional in security and I hoped there could be some way to protect our services from calling by unwanted entities. – anonim Dec 03 '13 at 07:29
@anonym It is theoretically impossible. Remember, all you can do is communicate over a network, and the client can tell you absolutely anything it wants. It could be a new client, it could be a hacked version of your client, it could even just be a playback of a recorded session from your client. Just like with people, you cannot just ask "Are you a liar?". – Chris Pitman Dec 03 '13 at 13:34

Kieveli · Answer 3 · 2013-12-02T20:16:03.517

The last time I implemented security, I used Apache Shiro. It provided a reliably secure method of implementing a secured client/server access to user data. Not only did it supply the hashing and crypto algorithms to ensure clear text passwords were not available, it also gave you a framework in which to use your security system. Each component could verify the current user's authentication level, and then allow/disallow various components to be delivered to the user.

I integrated with a GWT application which allowed for local user accounts, facebook accounts, twitter, linkedin, plaxo, and google+. It handled all cases without problems.

When Shiro integrates with your web application, it uses your server-side session to store an identifier for the current user. This is only assigned into the server-side variable when a client successfully provides valid authentication. They also implement a configurable timeout to restrict how long that authentication is good for.

One thing they can't protect is a man in the middle attack, but it isn't your position to secure against that kind of attack. Force the use of SSL, and you've covered your ass.

Check out this list of top 10 security risks as a primer.

As far as how that applies to your own client application, you will inherently be insecure. Typically, you would put a unique code within your application to allow only that application to communicate with your web service. Once one person downloads the client, that code is easily available. Any packet sniffer will be able to see the communications. Use SSL, and it's more difficult, but a decompile will provide the text.

If you restrict access to users that authenticate via your web service, then you're a good step closer.

It is trivial to man in the middle your own ssl connection with tools like fiddler. — , Dec 02 '13 at 21:30
You still need to get into a specific location to attack, or sneakily setup a proxy. — Kieveli, Dec 03 '13 at 11:58

Is it possible to check a client side application identity from server side?

3 Answers3