0

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?

Yinon Eliraz
  • 101
  • 1
  • 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](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) over the request which uses a shared secret. – Steffen Ullrich Jan 04 '17 at 16:42
  • In my case, a valid request is one that came from the my app client. – Yinon Eliraz Jan 04 '17 at 16:45

2 Answers2

1

Edit:

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.

Silver
  • 1,824
  • 11
  • 23
  • 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 05 '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 06 '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 07 '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 09 '17 at 09:40
  • I got a little lost. What are you suggesting? – Yinon Eliraz Jan 09 '17 at 10:01
  • You can't enforce that requests are coming from a certain client/app. You can make it hard for someone to mimic the requests that your app is sending by digitally signing them with a certificate that is shipped with an well obfuscated app. Why is there no secure way to ship a certificate with an app? Simple, because you are delivering the app and all it's data to a user controlled device. It can even be an emulator. You can only try your best to hide the certificate. You might wonder if you can't encrypt the certificate. Where are you going to store the decryption key? On the device! – Silver Jan 10 '17 at 08:48
0

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

Jasen
  • 834
  • 5
  • 8
  • If his client is a web application and his client side code is javascript. How does he store a secret? – Silver Jan 06 '17 at 13:27
  • HTML5 local storage – Jasen Jan 07 '17 at 01:38
  • Or prompt the user like a password – Jasen Jan 07 '17 at 01: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 09 '17 at 09:41
  • the client was a mobile [device] app, then you moved the goal posts. – Jasen Jan 09 '17 at 09:46
  • Sorry I don't follow you. – Silver Jan 09 '17 at 10:49
  • the question at the top of the page is discussing a mobile app , software than runs on a smart phone or tablet, this is compiled code so the source is not available and reverse-engineering it can be considered to be difficult. the client is not a web application. if it is there is less possibility for security. – Jasen Jan 09 '17 at 11:10
  • depends on the platform. Android compiles to bytecode which is very easily decompiled. There are solutions to obfuscate this code such as proguard but even then it is always possible to reverse. If the aim is to simply find a private key and not understand the full app, reverse engineering can focus on this part and often requires little effort. – Silver Jan 09 '17 at 11:18