0

I am part of a group developing an iOS application. This app accesses a database to both retrieve and submit data. One of the group members said that he does not want to have any direct interaction with the database from the app, but for data to go through a .php on a website.

His reason for having an intermediary php page is that he does not want the database password in the code because someone could decompile the app and look at the password.

Friend's idea:
App -> website (.php) -> database -> website -> app
As opposed to:
App -> database -> app

Is this a legitimate concern? If so, is this group member's php solution effective?

Thanks a lot in advance!

  • Please start with reading OWASP – Deer Hunter Feb 8 '16 at 13:27
  • 1
    Exposing a database to the internet and putting the password in an application you give to untrusted parties is a terrible idea, and the group member is right to be concerned. Personally I wouldn't trust php as it's long been a nighmare of security problems. – Steve Sether Feb 8 '16 at 14:57
  • 1
    Also, the more likely route of finding your database password would be simply sniffing the connection. No need to decompile anything when you can just find the username/password and DB URL on the wire. – Steve Sether Feb 8 '16 at 15:00
5

Your question is very confused. I'll assume that English is not your first language and what you are really asking is "should a DBMS be exposed on the internet?"

he does not want the database password in the code

That's just the start of your problems.

There are things you can do to make the problem less bad than what you are currently proposing, but they still leave a lot to be desired.

Use the credentials provided by the user to authenticate in the DBMS

i.e. the database password is the user's password. This restricts the use of the database to known users (as opposed to making it available to anyone on the internet) and removes the need to embed the database password in the client. But it doesn't solve any of the other problems.

restrict the accounts access to only run stored procedures

Done properly, this would prevent an attacker from reading stuff from the database they shouldn't have access to - e.g. they should only be able to see their orders and not orders from other people. It also allows you to implement your business logic on the serverside (you can't trust logic implemented on the client). You should never store data which has not been vetted for compliance. This also gives some scope for managing the user experience more effectively when things do not proceed along the happy path. However its really hard to implement application logic in procedural SQL.

restrict the access to specific IP addresses

Where only known IP addresses will be accessing a service, this is good practice - it cuts down on the noise, but its not foolproof. And your mention of an IOS app (I presume you are referring to iOS, Apple's mobile device operating system, not IOS, which is Cisco's network device operating system) suggests you won't be able to determine the client address in advance.

...but these are not nearly enough protection!!!

DBMSs are simply not designed to be exposed in a potentially hostile environment. And SQL, using the same channel for data and control, is particularly susceptible to abuse. Nobody has been able to fix these problems on a DBMS - and indeed, nobody is trying any more as the solution is to implement a proper control layer, serverside, on top of the DBMS.

1

I THINK IT IS making SENSE TO TRY THIS!!

IT is really confusing but the use of ajax solution would meet your requirements!

  1. write javascript codes then save as .js file! in the document... write the "GET"/"POST" Method with password and user name that will connect the app to the server or to the .php file... that will hold actuall connection to the server! for example:
    "function obtainData(datasource){ if(window.XMLHttpRequestObject){XMLHttpRequestObject.open("GET",datasource,userName,password);}...}"
  2. and then use the eval() function to let evaluation of the fetched javascript and or php during onreadystatechange, readystate==4 &&status==200;....
this hoever will be saved as an external javascript document that will be included using "<" script src="doc.js". . .">" which will result that when the document is viewed,the source code containg password will be seen as .js and not the actuall one! I THINK THE PASSWORD AND OTHER INFO WILL NOT BE PRONE TO MALPRACTICES AS IT WILL BE CARRIED IN THE .JS'S AJAX!

  • Do you think so? I don't! – F. Hauri Jul 17 '17 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy