Geek Answers Handbook

Web API Access Protection

I have a simple web API accessible via HTTP, with some relevant mobile apps reading this data. Now, someone decompiled the app / sniffed the HTTP traffic, got the URL of my web API and built its own client, acting as one of mine.

How can I protect access to my API only for my own clients? Even with the thought that someone is decompiling my application.

Changing the server and client code is an option!

+3
source share
4 answers

Changing the server and client code on the client side is an option!

Firstly, you cannot completely prevent it (without legal action :). Use SSL / TLS to help with sniffing.

If the application is downloaded directly from your server (and not through the app store / third-party manufacturer), you can provide it a little more. When the user downloads the application, make sure that the user is authenticated, generate a key, include it in the application and use it in all further communication with this user. A hacker / thief can imitate this, but they will need to go through their server to simulate the login and loading of your application - you can find and block it.

+3
source

Use TLS (successor to SSL).

In short, no one will be able to sniff traffic because it will be encrypted. The basic version includes only the server certificate - create a certificate (self-signed to run) and allow the server to use. What happens (I will not go into a handshake):

  • the client sends a request
  • the server responds with its public key
  • the client creates a symmetric private key (using AES or 3DES), encrypts it using the server’s public key (RSA) and sends it to the server
  • the server decrypts the symmetric secret key (only the server that owns the private key can decrypt it)
  • communication continues when each message (request / response) is encrypted with a secret key that has been reliably transmitted

Most of them are handled by the APIs that you will use, but it’s good to know how this happens.

+2
source

How to authenticate a web request?

Basic HTTP authentication is obviously inadequate if there is a risk that the traffic will sniff if it is not sent via HTTPS (which would be safe).

There are many other approaches - call-based mechanisms (e.g. digest authentication), client certificates, and SSL.

Actually, the question of which solution is the least pain - SSL certificates cost money, if you do not set up your certification authority (until you expect the world to accept your certificates, then it is quite simple to do it), Write code for implementation tasks / hash based on shared secret.

Or simply restrict the URL (via .htaccess) to a fixed set of ip addresses (optionally verified using IPSEC).

+2
source

Short answer: this is the beginning of the arms race. You can either confuse or defend your opponents' reengineering and recycle, or you can focus on improving your client software so that users are more likely to use your software than your opponents software. I would say that if your customers are the best tools, your users will use your customers. If there is something that your competition is doing better than you, pay attention.

The answer is longer: when each client boots up, create an x.509 certificate on the client side, sign it with the CA key. Configure your web server to require and verify a client certificate with each request.

One of your legitimate users may provide your client certificate to your adversary. They can bake in one, ten, thousands of different legally acquired certificates in their software, but you can knock down each of them (publish the key in the certificate revocation list that your web server uses when checking clients) when you find them, then contact individual end users who are disappointed when their keys stop working.

+1
source

More articles:


All Articles