Question

I have a project where I need to make secure transactions on a HTTP web server. I completely control the client (mobile application) and control the server. I want to develop a system where the client can add or subtract a value stored in the server’s database. The value stored is currency based so it is important that the number is accurate. My question is how I can prevent someone from reproducing the HTTP traffic and removing or adding values at will. Someone could take a packet capture from the client, view the HTTP POST parameters necessary to modify to server’s currency value, and just reproduce those packets whenever they want.

My first thought was to have the client encrypt the new currency value with a public key and then have the server decrypt it with a private key. I would also embed a timestamp and their username along with the new currency value before it gets encrypted so the request would always be different. The server would then check the timestamp and reject if it’s past 10 seconds. One problem with this approach is if the client or server are out of sync time based. Server would be synced with NTP but there is no guarantee that client will be correct

Any other ideas would be appreciated. I’m not looking for low level implementation details, just the high-level overview. Ideally the solution would not be too taxing for either the client or the server since the rate of transactions will be high.

Answer 1

A general security tip: You do NOT control the client if it’s out in the wild! The server must check everything the client sends.

Simple flow:

• Client connects to server with a username/password via SSL, setting up a “session”.
• Client sends a command (increment product X by amount Y)
• Server receives this request through the SSL connection
• Server checks the request is valid, that the logged-in user is
  allowed to do this, executes the command and sends a response to the
  client indicating failure or success.
• Client disconnects, sending a “session terminated” message (the
  session should also timeout after a set period as well).

Note:
Everything must be authenticated and checked server-side! Your client application should not be the one in charge of working out what is a “valid” request and what is not – that’s the job of the server. Each request should go via SSL, and should only be executed once the client has successfully logged on and started a session. Even with a timestamp-based check, someone could reverse engineer your client or use a man-in-the-middle attack, but only if they have a username/password (or are able to intercept a legitimate client’s data – hard with SSL/public/private key system). If very strong security is mandatory, every request from the client should be encrypted by RSA.