Securing a web service to prevent tampering of exchanged data and simulation of application requests

I'm building a web service with a client API library. How can I help the developers who use the client API library to prevent end-users from modifying the data exchanged between the client application and the web service?

Also, how can I ensure that the requests come from the application and aren't simulated by an end-user who simply calls the service directly?

I know there will be workarounds for any security implemented here so the question is not how to make it tamper-proof but rather tamper-resistant.开发者_高级运维

---

You really can't.

What you want to do is encrypt your payloads. Encrypting the payload ensures that someone in the middle can not tamper with it, and that the payload is created by someone with a proper key. To do that, you need to get a key. To get a key you need to either embed it in your program, or request it from a server. If you embed it in the program, it's accessible by anyone with the program. If you request it from the server, then you need some artifact to identify the proper key to send to the program -- which is effectively some kind of key in its own right.

Encrypting the traffic will thwart most people. The problem is that it won't thwart all, and the people who persevere, then publish their information in a form to make it easy for those not willing to do the work initially.

That's why it comes down to what you're trying to protect.

For example, if you're playing a game that scores points and if you get enough points, you win great prestige or, as bad, money/prizes, then there is proper motivation to cheat and work around the safeguards. If the user is rewarded in any significant way by cheating, then not only will someone cheat, they'll enable others to cheat.

This is why "security by obscurity" doesn't work. It's all centered on the motivations of those trying to break the security, and the security, once broken by the once sophisticated analyst, then, suddenly, "everyone" knows about it.

Consider the recent Sony Playstation hack. That system was quite secure, but someone, somehow discovered the signing keys that allows an um-modified system to run software. When those signing keys were secure, then the level of burden required to "hack" a PlayStation involved hardware modification, etc.

Now they don't require anything. It's a download. And the entire PS community is now untrusted. That cat is out of the bag.

A similar thing happened to TI Calculators, someone reverse engineered the signing key busting the platform wide open. And that's just geeks with calculators.

These are just extreme cases of what can potentially happen to your protocol once the security is breeched. So it's important to understand what the drive is hack your solution first, and then try to mitigate it through some other means where the payloads and encryption of them are less important to their success.

---

The best solution is to use HTTPS to prevent tampering on the wire. However, often times, the client has more control over the environment than the developer. This is especially true for all mobile platforms. You will be unable to hide an API key or prevent a API call from being manipulated in memory prior to its transmission. There is no security system that can prevent this from happening.

Perhaps you are looking for "(in)Security though obscurity."