如何使用REST API或其他方法保护JSON文件？

Question

I've searched everywhere, and found lots of information I cannot comprehend. I'm using a WAMP server and managed to execute a "SELECT name FROM Tablename" query and passed the data to json_encode() . I like the results so far, but now I need to protect the JSON file in the server, making it accessible only to users that run my Android app.

Through my research I found that REST might be a solution for me but I do not understand how I can implement it for my case. Is it possible to have Server-side REST Security, and Client-side as well? I understand that REST is a web service and I read a tutorial where the web service is basically a web page. My priorities are server-side json file, security and speed. The user will not be inserting any information via the Android app. I was thinking of deploying the Android application with the user and password to the specific json file (verification).

It would be helpful if you can point me to a video tutorial, or a tutorial for beginners, related to the subject.

Here are my specific questions?

• Can I parse images with JSON?
  
• Is it more efficient to mysqldump --> convert .csv file ---> SQLite? (Securely).
  
• How big can a .CSV file get with say 1 million entries in the database?
  
• How can I accomplish all this?
  

Please help, thanks.

Answer 1

Solution: Use HTTP Headers

Insecure solution:

use the User-Agent header.

User-Agent: MyAndroidApp/1.0

More secure solution:

First off, you'll need to use SSL so no one can just easily see your secret key.

Second, you can put a secret key in the HTTP header of the request you make from the android app:

X-Android-Secret-Key: fee400be-7d08-45c5-bf7c-ff79c35a838c

You check headers on the server and only serve the file back if the desired header is received. You keep the header somewhat secret but not impenetrable with SSL.

Answer 2

I'm only going to answer your original question on app authentication. Your other questions belong as separate questions.

If it's only your client and your server, you can (and should) use mutually-authenticated SSL without purchasing anything. You control the server and the client, so each should only trust one certificate, the one belonging to the other and you don't need CAs for this purpose.

Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.

A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.

You'll normally store that certificate/private-key in a keystore of sometype (a KeyStore if you're using Android) and that keystore will be encrypted. That encryption is based on a password, so you'll either need to (1) store that password in your client somewhere, or (2) ask the user for the password when they start your client app. What you need to do depends on your usecase. If (2) is acceptable, then you've protected your credential against reverse engineering since it will be encrypted and the password will not be stored anywhere (but the user will need to type it in everytime). If you do (1), then someone will be able to reverse engineer your client, get the password, get the keystore, decrypt the private key and certificate, and create another client that will be able to connect to the server.

There is nothing you can do to prevent this; you can make reverse engineering your code harder (by obfuscation, etc) but you cannot make it impossible. You need to determine what the risk you are trying to mitigate with these approaches is and how much work is worth doing to mitigate it.