0

This is the first time I face a mobile app deployment at big scale. This app needs to connect to a remote server where to store and retrieve data.

I discarded connecting directly to the MySQL database as it would be a very bad idea, so I put some PHP scripts in the server side that receives data from mobile devices as HTTP POST queries and produces a valid response depending on the query.

Now I'm starting being concerned about security using this approach. Anyone may connect to their home WiFi and set as the gateway some local machine and start sniffing traffic, this way it would be very easy to know which queries are being sent and how to tamper some queries to get/send unathorized data.

To prevent it, I have considered the following approaches:

  • SSL: Seems obvious, but as far as I know, SSL will encrypt data in the wire transaction but still is able to be sniffed in a local machine.

  • Encryption algorithm: Encrypt both on the client and server side messages with some secure encryption. This would face some other issues, though, as hardcoding some keys in the app, which seems not a big deal.

I'd like to avoid using third-party add-ons and use my own code to do all the stuff, but at this point I'm stucked on how to procceed.

Any ideas? Thanks!

nKn
  • 669
  • 2
  • 8
  • 14
  • 3
    Do you want to protect the network traffic against an *outside attacker*? Then use TLS, password and username. Do you want to protect the network traffic against *the user*? Then forget about it, that's impossible. – Philipp Mar 08 '14 at 14:09
  • My aim is to protect the data sent from the user's mobile device to the remote server. It's obvious the user will be able to sniff anything if connected to their own WiFi connection, so really there's no way of at least make it difficult to the user to know the message being sent to the remote server? – nKn Mar 08 '14 at 14:28

2 Answers2

2

@Philipp is right when he says that you can't protect against your customer.

Instead of going to great lengths to keep the pseudo-queries secret, you should focus your efforts upon input validation and injection protections. On the server where you take the pseudo-query and translate it to a SQL query, make sure that you're properly quoting any input to the SQL query, and perform basic sanity checking to raise the barrier against abuse. A WAF could also help here, but if you're writing your application, you're in the right time and place to put proper protections in situ, which is even better.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Thanks for the answer. My biggest concern is that the user might know the HTTP POST query being sent to the remote server, and this way construct their own PHP script which will, for instance, change the login being sent into the query and get some data from the user, but I'll have special care to not retrieve anything that might be sensitive. Oh, the remote script is indeed injection-proof, that's basic to me. Thanks again! – nKn Mar 08 '14 at 14:39
  • ["System security should not depend on the secrecy of the implementation or its components."](http://en.wikipedia.org/wiki/Security_through_obscurity) The password should be a secret value, the format by which the login and password is submitted to the server must not need to be. – gowenfawr Mar 08 '14 at 14:52
  • 1
    "make sure that you're properly quoting any input to the SQL query" Or, better, use Prepared Statements. It's easier to get right, faster, and more secure than by hand/"real_escape_strings"-ing for completely and totally preventing SQL injection attacks. – Kitsune Mar 08 '14 at 16:02
0

Based on existing comments, answers, and some more elaboration from you, I'd say your scenario is something that Microsoft tried to create a solution to with Next-Generation Secure Computing Base (NGSCB) which was also formerly known as Palladium. Without encrypting everything (code, memory, data in the processor, data traveling on the bus, data moving to/from the network) and making the key inaccessible to the user, you cannot 100% guarantee that your code is operating to your specifications. As @gowenfawr implied, the best way to keep things safe is to run as much of the code as you possibly can on hardware that cannot be tampered with by the user such as your server. For example, many MMO games will only send player input to the server and calculate the physics on the server itself; the player runs a client which only serves to collect input and render the output from the server. You could say that the safest approach is the thin client approach.

Kevin Li
  • 601
  • 4
  • 6