PHP Security - Worst Case Scenario: Public, Hardcoded Password

Question

Being primarily a front-end developer, I want to better understand the limits of server-side security with PHP.

Let's say I had an Apache server containing a MySQL database and only an index.php file. The (bad) design is as follows:

1. A database containing private information, called "top_secret_database"
2. A single table in that database, called "juicy_data"
3. A column in that same table that has non-private, non-interesting information called "not_important_column"

4. The contents of index.php are:

   <?php 
       mysql_connect("www.example.com", "db_user_name", "foo")
       or die(mysql_error()); 
   
       mysql_select_db("top_secret_database") or die(mysql_error());
   
       $not_secret_column = mysql_query("SELECT not_important_column FROM juicy_data") 
       or die(mysql_error());
   
       echo "The password to my Top Secret Database is <strong>foo</strong>.";
   ?>
   

Obviously you can't peruse server-side code like client-side code, unless something went horribly wrong with the server or code (Can a client view server-side PHP source code?), and there are of course ways to keep even a hard-coded password safe(r) (Securing DB password in php).

However, my question today is, even if I outright told people my database password like in the index.php file above, what are the ways, if any, that an attacker can access the other (interesting) columns of the table that was just queried automatically by the above script?

Answer 1

This is really a subjective question, but I'll try to take my swing at it. Taking your example above, things could go wrong, for example, if:

• You accidentally used the same password for the code above as another user on the system. The user may not even be a MySQL user. It could be an SSH account, or even root. In fact, why stop there. Maybe you use the same password for your Gmail account. With that, they do a password recovery from your Amazon account and use the last 4 digits of your credit card to log into your home computer and erase all your files. While they're at it, they break into your PayPal and send a few payments to themselves. Think this sounds far fetched? Think again.
• Your MySQL server is (mis)configured to listen for incoming connections from anywhere, and with that a user could log in and do whatever they want in your database. Or perhaps it's only listening for connections from LAN IPs. Then someone finds out what hosting provider you use and orders another server in the same LAN and uses that to get in.
• You are (or maybe will be in the future) using a shared hosting plan. Then anyone on your server could easily log in with your credentials.
• What if someone contacted your hosting provider and convinced them that they could log in to MySQL but they need help getting into FTP. Providing the correct credentials, someone may be more convinced that they are the account owner.
• Don't forget small windows of opportunity. If any of the above don't apply on a large scale, perhaps you simply, for 5-10 minutes during testing, open up a small window where one of these does apply. Maybe for some reason you decide to see what would happen if you set MySQL to listen from any address to rule out that that's what is causing something else to fail, and poof! There goes your DB because people have the password. Things on the internet can happen extremely fast and many times without you even knowing.

Any little thing you can do to secure your code is better than nothing. No security is 100% perfect, but the more holes you plug up, the more difficult it becomes to crack your security and do some really evil things. As my first point above shows, it may be something completely unexpected.