I have some code in my iOS app like this:
URL *url = [NSURL URLWithString:@"http://urltomyapp.com/createaccount"];
ASIFormDataRequest *createAccountRequest = [ASIFormDataRequest requestWithURL:url];
[createAccountRequest setPostValue:email forKey:@"email"];
[createAccountRequest setPostValue:password forKey:@"password"];
[createAccountRequest startAsynchronous];
In my server implementation, I simply take this information via self.request.get('email') and create an account, not doing any checks or anything. However, it seems that anyone can run the above piece of code easily (I mean all you'd need to do is copy the above code and put it into your own app, right?), all they'd need to know is the server address and they can attach any data they want to the request, and the server would go ahead and create an account for them.
How would I authorize requests to know that they are coming from my app and my app only? Is this a common concern? How do other products protect against this?
First, a disclaimer. I am certainly not not a web expert, nor am I a security expert. In fact, the only reason I'm answering at all is because of the discussion in stackmonster's reply.
However, I do know that intercepting an SSL connection is exceptionally easy, especially if the user is complicit.
In general, though, I think the following is of some benefit.
You have to determine who/what you are trying to protect. If you just want to protect the data in the communication between the app and the server, https will be just fine. External snooping will be as effective (or ineffective) as snooping other SSL traffic.
However, if you are trying to protect your API (which your question seems to suggest), it is trivial for a user to see what commands you are sending (as you, yourself found out by using Charles).
So, do you want to prevent anyone from knowing the details of your API? Do you want to just prevent DOS attacks, or only let valid users issue commands, or what?
You can then worry about authentication and authorizations (two different topics). Maybe validating that the request comes from a known entity is enough.
Anyway, it is extremely difficult to give guidance because you first have to decide what your networking privacy goals are.
Then, if they are lofty, you are in for a lot of reading.
At some point, though, you have to decide what is crucial to your app/business, and what is not. Just like any good software design, then create a set of requirements. Then, prioritize them in some order (e.g., mandatory, essential, nice to have, can live without).
That will tell you if you need additional security, and what kind.
Most, however, find that it's not worth the time and investment to even lock all the doors and bar the windows (not to mention protecting the chimney, adding concrete to the walls, floors, and ceilings, building a safe-room, and hiring armed guards).
use HTTPS and put a cert inside your app to verify the client is allowed to talk to your server.
But trust me, its really not worth all that. Using HTTPS is generally ok on its own.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With