I am using an http server on Amazon Web Services running php and connecting to an RDS DB, also on AWS.
I am sending GET requests to the server to get Information.
The requests dont contain any private information.
I am trying to think of the best way to secure the requests as much as I can within the GET limitations.
The reason is obviously to make sure only valid requests reach the server.
One way I thought of was to pass a token that allows the server to recognize the request as a valid one. I just could not think of a way to generate a token that is not constant and can be calculated by the server and the client.
Is there a better way? In general, what is considered a good approach for this kind of problems?

  • If you could describe what a "valid request" exactly is in your use case one could maybe help with the question. Examples might be specific (authorized) sender, specific syntax of request etc. If its about finding out if your app is the likely origin of the request you might use a HMAC over the request which uses a shared secret. – Steffen Ullrich Jan 4 '17 at 16:42
  • In my case, a valid request is one that came from the my app client. – Yinon Eliraz Jan 4 '17 at 16:45


In light of the new information (it's a mobile app, only requests from this app should be allowed) this post is updated. The old answer was removed as not relevant.

The OP wants so ensure that requests are sent from his mobile application and not some attacker defined program. This kind of assurance is normally achieved by digitally signing the requests using a certificate (public and private key) at the client side and using the public key at the server. If applied to the scenario of mobile applications, the certificate should be present in the application (shipped together or transmitted when the app is first used) in order for requests to be signed.

Now assume the attacker wants to craft his own messages to send to the server. For these requests to be accepted they need to be signed. To sign those messages he needs the private key that is contained in the app one way or another. The attacker downloads onto an attacker controlled device. Since the integrity of the mobile device can't be guaranteed (device may be rooted, emulated, ...) there is always a way of obtaining the certificate. The only thing you can do is trying to make this retrieval VERY hard. Obfuscating the application can help against static analysis but one also needs to make sure that the certificate is hard to find in memory at runtime.

To prove the difficulty of this problem, let's take Pokemon Go as an example. Within days of it's launch, someone had intercepted network traffic from the app to the server and wrote his own program (running on a desktop computer or laptop) that mimics the behaviour of the app (sending updates of the position of the player, throwing a pokeball, etc.) that automatically played Pokemon Go. This is known as a 'bot'. The developers releasef several updates to protect the requests (I assume they tried digital signing as well) but every time the attackers where able to reverse the logic and craft their own requests. The only thing that really worked was looking at patterns in the requests at the server side to detect that they were coming from a 'bot' instead of a legitimate mobile app. Things they will have used is timing of the requests (exactly 1 second apart), location of the player changing in certain patterns, etc. If a player was assumed to be cheating by using a bot, he got banned. Attackers responded to this by adding some randomisation to their requests to make the analysis harder. So it became a cat and mouse game between attackers and defenders. Pokemon Go also sent cease and desist letters to people they could identify as developer of the bots. This shows how powerless they were against the problem.

| improve this answer | |
  • The server is accessible only from the client app, with the token. But my question was what sort of token should I use and not weather or not to use one. – Yinon Eliraz Jan 5 '17 at 14:32
  • Sorry Yinon but you need to provide more information: What type of client (web application, mobile application, fat client,...) Who has access to the client side code? Anonymous users? is the client distributed to a few individuals? Do you care about someone taking a valid request from a valid client and just resending it? Do you have a method of storing a secret in the client that nobody can obtain or is hard to obtain? Should an attacker be able to modify the request? Or do you want to do integrity checking on the request (digital signature)? What technology are you using? – Silver Jan 6 '17 at 13:26
  • The client is a mobile app. The code is not accessible to users. It will be available to users from the app store/market. I would like to be able to separate requests from the app to any other request and only accept the ones from the apps. I have no secret data but storing a secret string can be possible. I am using a php server on EC2 client on AWS with a MySQL database on AWS RDS. – Yinon Eliraz Jan 7 '17 at 17:15
  • Mobile apps can be reverse engineered. You need some damn good obfuscation to hide a secret. The other solution is to send a secret to the app. But what prevents an attacker from requesting a secret from your back-end? To be honest, Pokemon Go didn't even succeed in doing what you are trying to do. You can't enforce that a request comes from a certain client that is distributed publicly since everyone has access to the code which depending on the platform is hard or easy to reverse engineer. – Silver Jan 9 '17 at 9:40
  • I got a little lost. What are you suggesting? – Yinon Eliraz Jan 9 '17 at 10:01

for your token use a hash of the current time, a secret, and the rest of the query.

| improve this answer | |
  • If his client is a web application and his client side code is javascript. How does he store a secret? – Silver Jan 6 '17 at 13:27
  • HTML5 local storage – Jasen Jan 7 '17 at 1:38
  • Or prompt the user like a password – Jasen Jan 7 '17 at 1:40
  • Then you are either sending the secret to the client. The attacker can also request such a secret from the backend. Or you are using passwords which authenticates the user, not the client. The OP want to be sure that requests come from one client which is not possible. – Silver Jan 9 '17 at 9:41
  • the client was a mobile [device] app, then you moved the goal posts. – Jasen Jan 9 '17 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.