2

I'm building an iPhone application that has to communicate with a MySQL database through a PHP API.

Now obviously, I don't want anyone to have access to my database. Therefore, I want to put some decent security in the API and the app.

After some research, I found out that this may be a good way:

Building Secure Public API with PHP/MYSQL

It basically says that the code performs some math on the variable entered by the user on the app side. This math returns a value. Then, you perform the same math on the variables on the API side. if the values are the same, you know that the API gets save request.

The problem is, the SO post I linked to above is about an PHP application AND API. I have an app written in Objective-C and a PHP API, but I want to perform the same kind of trick.

Is there a way to put this kind of security into a service with a Obj-C app and PHP API? if not, what would be a better idea to secure my service?

Community
  • 1
  • 1
Joris416
  • 4,751
  • 5
  • 32
  • 59
  • 1
    Math is math. You can write any mathematical procedure you want in ObjC. – jscs Nov 04 '13 at 21:06
  • 1
    What sort of attack do you imagine this will protect against? Are you worried about a third party making requests against your API, protecting your users from malicious users intercepting traffic in flight, or protecting your api from abuse by users of your application? – Jonah Nov 04 '13 at 21:23
  • @Jonah I am trying to prevent a third party making requests against my API in order to prevent the information from my users to be abused by anyone. My app is the only thing that I want to have acces to the API. Do you have any idea how I realize that? – Joris416 Nov 05 '13 at 10:39
  • 1
    Keep in mind how valuable your data is to the most interested 3rd party. Protect it against that level of threat. On the high end there are software companies in China and elsewhere where all they do is work on break-ins as a full time jobs. Protecting against a government is difficult to impossible, some (CIA?) in addition to software also have "rubber hoses". – zaph Nov 07 '13 at 01:27
  • @Zaph I am not even aiming to protect my database against the NSA or some comparable kind of service, because I totally agree that that's impossible. I want to protect my database against people aiming to place orders in the name of somebody else, and people that want to put all the information from the database on the public internet. – Joris416 Nov 07 '13 at 09:45
  • In the second case you are protecting against one entity, the most determined. Can that entity will succeed if they can access just one account? If so one bad user name password combination is all that they need. Just one person who uses a password from the most used list, say "password" as one example. In my case I do not allow users to create their own passwords. The next attack may be from another user of the same system, that can happen if you use shared hosting instead of a dedicated computer. You will need sessions of some type. – zaph Nov 07 '13 at 12:19

2 Answers2

3

If you don't want anyone to have access to your database, why are you not using a simple authentication using sessions. NSURLConnection handles cookies sent from server.

And "perform some math" approach can be achieved easily as you are using universal math operations to calculate some hash to use in validation of requests. It doesn't matter which language you are performing the math operations on as long as you do them correctly.

erkanyildiz
  • 13,044
  • 6
  • 50
  • 73
  • the "some kind of math" that I was talking about is this(in PHP): $signature = hmac_sha1($base_string, PASSWORD); (see link in question) Is that kind of line also available in objective C? – Joris416 Nov 07 '13 at 09:48
  • Usine HMAC is no longer a best practice, instead use PBKDF2, see this [SO answer](http://stackoverflow.com/a/9372343/451475). – zaph Nov 07 '13 at 12:22
2

A couple of things to consider as you try to select an appropriate set of security practices.

  1. Does your proposed scheme keep any sensitive information confidential? Will it prevent me as a malicious third party from reading all of your users' communication even if I cannot control any of the messages or otherwise impersonate them? As proposed I don't see anything that would prevent an attacker from watching these requests and responses. Maybe that is not a concern here? If it is requiring a SSL connection would go a long way to prevent such eavesdropping.

  2. Do you have an effective means of authenticating your users to establish their identity? If I can impersonate some other users I can probably read or overwrite all of their data. This is often handled through some form of user session created when a user correctly answers a security challenge. For example a user might enter their password or provide an oauth token from a third party like Facebook and then be given a cookie or session token to identify them for some period of time. An effective scheme will not allow an attacker to easily guess these session identifiers or steal them for the attacker's use (see point 1 above).

  3. Once authenticated do you enforce authorization rules limiting what data a user may access? Even if you know (or at least believe) that I am a legitimate user of your API you should not trust me to only attempt to access my own data. I have seen a number of public APIs, particularly for mobile apps, fail on this step. In many cases it is trivial for me to follow a perfectly legitimate authentication process using your own app. Once I have done so I am free to use that legitimate user account and your own app's authentication process to craft whatever requests I desire against your API. You must not blindly trust clients of your API to be well behaved. A common objection I hear to that last point is "but we wrote the only client app". Unfortunately writing the client does not mean you control it. As soon as that app is in your users' hands its behavior is no longer a secret. Your clever encryption scheme will be extracted, reimplemented, and used to make arbitrary API requests from curl. If that proves difficult it will be reused in place as an attacker calls your sendEncryptedAPIRequest method with their own parameters. Rather than attempt to keep your client's behavior secret while still making it available to your users it is better to enforce access controls as part of the API.

  4. Where possible do you verify the integrity of the data you receive from a client? Even if I can only access my own data are you trusting me to provide reasonable values and what are the consequences if I do not? For an example look at almost any iOS app with an online leaderboard or high score list. If you trust a client to report their own score incredibly some of them will report very high scores indeed. Depending on what your app does and if any data is shared this may be more or less of an issue.

This does not leave you with a simple "do this and your API will be secure" answer but I'm afraid that is the reality of the situation. Security needs to be an ongoing consideration at every level of the software you build. Fortunately your requirements are unlikely to be unique so libraries and common practices exist to help with all of the areas described above.

Jonah
  • 17,918
  • 1
  • 43
  • 70
  • 1
    Excellent advice! Additionally, have your method and code reviewed by a security domain expert! Oh, only if you really want the data to be secure. True security is hard. – zaph Nov 07 '13 at 01:30
  • Sorry for the late response and thank you for you tips. I have been busy with other things but that's over now. I have looked into oAuth authentication. Knowing that my database contains usernames, passwords, orders, products and information from companies and users, and that the API is able to change, create, delete and read all of the previously mentioned information, would this oAuth authentication + a unique secret key be enough security to keep malicious third parties out? I will also put in code to prevent SQL injection and limit the traffic per user. – Joris416 Nov 15 '13 at 20:18
  • Oauth provides authentication (and is effective only if the tokens it exchanges remain confidential). That covers 1, maybe 2, of the concepts above. Even if those components are resistant to attack (they probably aren't) that is far from a complete solution. In any case I think it would be a disservice to suggest that any scheme you propose here would be adequate without actually reviewing the design and implementation which is outside the scope of a SO answer. – Jonah Nov 16 '13 at 01:38