I am working on a mobile app using Corona SDK. One of its core functionalities requires sending data between the app and my server. My question is, at what point do my attempts at making the data transfer secure become redundant?
The server side consists of a few PHP files and a single MySQL database. I have an SSL certificate and I validate the data at both ends. The app itself only makes network requests via HTTPS/SSL using HTTP POST and the data being transferred is a JSON string.
To this point, I believe that I have done everything as they should be done. However, as an extra precaution, I also encrypt and decrypt the JSON string at both ends using AES256-CBC.
Is this extra encryption at all necessary or is it redundant?
HTTPS protects the transport between the client (browser) and the server. It specifically does not protect data at rest at the server side (i.e. inside the database) not does it protect the transfer of the data between the PHP application to the database.
It is unclear if any protection outside the transport between client and server is needed. But it seems that your AES encryption will only protect the same path as HTTPS already does. In this case it will likely not add any protection. It might maybe add protection against legal (or malicious) SSL interception but if the encryption key is send over the same communication channel as the encrypted data then it will not actually add protection.
Related
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.
I have two web applications which need to communicate data between them, for example when an employee is added in Application A, i make a CURL request / POST request ** and pass some of the employee data and Store it in **Application B.
The functionality is working fine, now i want to make the request flow secure, these two application i.e. Application A and Application B are on two different WebServers built on different technologies. One in PHP and Other in Java.
So when a record is added in PHP i send CURL request and save data in java. **The PHP application is built for distribution which would be sent to the end users.**
How i can make sure that the POST requests i send are secure. Any ideas?
How i can make sure that the POST requests i send are secure.
Well, the answer depends. Who do you want to make the requests secure from? What kinds of attacks are you worried about? I'll go through a few possible vectors here:
The End User
It is impossible to protect against an end user attacking your system.
Given that you're distributing the application to them, and they control the networking stack, it's literally impossible to 100% protect against the user from doing something nefarious.
You could obfuscate the source, and do all sorts of tricks to make it harder, but ultimately if the user has the program, and its running on their hardware, they can do what they want with it. Including attempting to extract encryption or authentication keys from the application.
An External Attacker
To protect against an external attacker without access to either system, there are some steps to take.
Use SSL for the communication.
This encrypts the traffic so that an attacker cannot see or modify the data in transit.
Use certificate pinning
In the application that you ship to the client, include a copy of the certificate that you use for your server. That way you can detect an attacker who tries to masquerade as your server (via DNS spoofing, or other attacks).
Verify SSL Peers.
This forces CURL to check the certificates to ensure they match.
Authenticate the client using secure cryptography
Generate a public key / private key pair. Store the private key on the client, and the public key on the server.
When issuing a request, sign it using the private key, the time of the request.
On the server, when you get the request, validate that the request time is greater than the last seen request (to prevent replay attacks). Then validate the signature using the private key, then store the request time as the last seen request.
Don't roll your own crypto. It won't help. Security Through Obscurity is not security. At least when it involves cryptography...
Here are some points which may result in surity of secure data transfer:
Use of SSL requests will be helpful.
Use an app token which will only known to applications. So while receiving and sending data you verify that token.
Try encrypted data transfer using some mechanism known to applications only, if don't want to use SSL.
Your own Algorithm to encrypt decrypt the request and its parameters, which only the receiving, sending applications will be knowing.
Many more..
I built an application in an objective c that performs user registration into DataBase (MYSQL) using PHP with METHOD - GET.
Is there any way for me to know if the received parameters came through the app and not via computer or manually?
I mean, anyone can discover the address of the server running the PHP code and embed
some manually parameters as: reg.php?name=someuser&pass=password.
If your application has some kind of secret token and you use HTTPS with certificate validation then it's less likely to be a problem.
Remember that the contents of your application can be read by the user if they're determined, and the contents of your API calls can be intercepted and examined with a proxy application if you're not careful to validate the SSL endpoint against known-good certificates.
Normally registrations are sent via POST, not GET.
You can either transmit the secret directly, as a sort of proof that you're using the Objective-C application, or to make it harder to discover, then by signing your request using something like SHA256 where that secret is a salt.
The short answer is that yes, this is a security vulnerability.
Resolving this security vulnerability via $_POST Method
If you were to use the $_POST method instead, name and pass would be passed in the document's headers; going undetected in the URL. Then your web application could test for the presence of these variables, which would allow you to reject users who try to access the script from outside of your Obj-C app.
Better yet, also include a security token or hash parameter in the $_POST method, and test for the presence of that in your web application. On top of this, don't forget to clean your input before you allow it to touch your database, as an extra safety precaution.
Fixing further security issues & vulnerabilities
The web application might use HTTPS.
Should check for the presence of other environment variables to indicate if the client is accessing your website from the Obj-C environment.
I want to send very sensitive data to a webserver by calling a specific php file with data over GET or POST (not sure yet). The data contains 3 values, so I thought of building an own algorithm, but this could be reverseengineered easily and I guess there are far better solutions than those I have.
The difficulty is basically this: When a user buys a inapp purchase for a Windows App he gets access to this server. MS does not offer any OAUTH check like Google does so developers have to implement their own check. Also we don't have any user accounts.
Do you have any ideas on how to restrict users that haven't bought the purchase from accessing this server php file (which is secure)?
There are lots of 'handshaking' methods you could use. One method that has worked for me:
Open the channel to your server
Server sends a string of random characters to the client
Client hashes the string with a known salt and sends this string back to the server
Server compares the returned string with it's own encrypted version of the original string
If they match then the client session is allowed
This prevents someone from doing a replay attack on your server.
If you want to stick with a typical 'web transaction' then use HTTPS (port 443) to handle your encryption. Another alternative would be to use an encrypted socket to a different port.
I have an iPhone app that is using my php api on the server but it is currently open if someone knows the url. I want to make sure that no one can use this API until I am ready to make it a public api (if I even do)
I have read this article but I am unsure what they mean when they say:
[CLIENT] Before making the REST API call, combine a bunch of unique data together (this is typically all the parameters and values you intend on sending, it is the “data” argument in the code snippets on AWS’s site)
I don't understand how if I hash the parameters I plan on sending with my api secret how this is more secure than just hashing the api secret if I send the parameters/values unencrypted.
HTTPS the API and use an API key. Then you'll know that only people (you in this case) with the key can have access to the API.
You're correct about it not being more secure. That's why I suggest you SSL the connection. Unless you plan on encrypting everything you transmit back and forth.
The public/private key scenario will also work well. HTTPS requires very minimal effort.
Digital signatures provide a way of validating a message sent over an insecure connection.
Setup: each client will have its own private key and public key (only the private key needs to be stored on the client). The server will store the public keys for each client. The public key can be visible to all and can be used by the server to identify the client. The private key, known only to the client, it is never shown to anyone.
The client signs the request: along with the rest of the request data, the client will hash the combined request data and encrypt the hash with the private key. The server will generate the hash the same way (leaving the signature out of the hash calculation), then decrypt the signature using the public key. If the hashes match, the request is authentic.
Note that HTTPS allows for client certificates, so you can leverage existing tools to accomplish all of the above without writing a single line of server-side code (you just have to configure your web server; the only trick is to make sure the server only accepts certificates it already has). Moreover, the amount of client side code should be minimal: you shouldn't need to do much more than set the connection to use the client certificate. Since you're controlling the clients, you can use self-signed certificates and add the server as a certificate authority. There are a number of questions on SO about using client certificates in iPhone apps; you can start by reading through them.
Note also that any scheme to protect the web API only works so long as copies of the app are in trusted hands. Should anyone untrustworthy get ahold of it, they can use the app or extract any secret data used by the app and access the API as they will.
For development purposes you can just use your web server settings to allow requests from your ip only.