3

I've just started studying PHP and having concluded my first PHP & MySQL for dummies book I have a concern about having a secure connection between my PHP application and MySQL database.

From what I learned, one approach is to create a .php file with the database credentials, for example:

--- database.php ---

<?php

define('HOST', 'localhost');
define('DB_USR' , 'mysql_username');
define('DB_PSWD' , 'mysql_password');
define('DB_NAME' , 'mysql_newbie');

?>

and then place a require_once('database.php') in every PHP page that requires any sort of database queries.

My concern is whether this approach is safe. Isn't the file database.php accessible to everyone once it's placed on the webserver?
Anyone can potentially read the database's credentials and mess his way around it?

Any thoughts?

Don't Panic
  • 41,125
  • 10
  • 61
  • 80
Filippos
  • 93
  • 1
  • 8
  • 2
    No it is not accessible because if you try to access it on web server, it will render the php and wont display anything.So, it is fine. – Mohd Asim Suhail Feb 08 '18 at 16:08
  • 4
    Include it in a file outside your web directory. – Jason K Feb 08 '18 at 16:08
  • As @JasonK said, store it outside the web tree; but also sort out your MySQL user permissions so that even if someone *has* the login details used by your website it will only be of limited use unless they also have access to something running on the same server (e.g. you've got a PHPMyAdmin install). – CD001 Feb 08 '18 at 16:16
  • Its safe enough to keep it in the web root (a lot of 'canned code' have their db inits in a single file in their root directory, for example), but I've always liked putting the credentials file *outside* of the web root, and access it from a global config file. – IncredibleHat Feb 08 '18 at 16:16
  • 1
    I don't see this question being about remote logins to a mysql server. – IncredibleHat Feb 08 '18 at 16:25
  • 1
    Make sure that you don't commit `database.php` into your version control repository. Instead, commit a template (e.g. `database.php-template`) and ignore the actual file. This way: 1) You don't need to use production password in your developement box 2) Password is not stored forever in your version control history for everyone to see. – Álvaro González Feb 08 '18 at 16:32

2 Answers2

6

The first things you have to look at are the different attack vectors.

One vector is remote users coming via HTTP, the other main vector is local users with shell access or similar on the machine.

Protecting against the first one is relatively easy: Make sure the content is not shared via HTTP. A simple way is to call the file .php so that when a user guesses the name the PHP script is executed and produces no output (that's what you already did) Slightly better is to prevent access to the file from the server config. Both of those approaches still depend on your operations, to make sure you don't break the config by accident. Better is to move the file outside the web root, into a completely different directory. Files outside the document root can't be accessed via the server and thus never leak.

For preventing local attacks the protection is to restrict access rights to the web server (i.e. make it owned by the web server and giving reading permissions only to that user account), this however still leaves a vector open for an attacker who can install scripts in a different vhost of the server (if it is a shard server) the mitigation there might be PHP's "open_basedir" setting, where PHP prevents access to files in a different directory. This has to be configured per vhost in the server's config.

Don't Panic
  • 41,125
  • 10
  • 61
  • 80
johannes
  • 15,807
  • 3
  • 44
  • 57
0

There is no echo or other output in the database.php so no one will be able to read it's contents on the web as it will render an empty page. Another good idea to put this file into a directory not accessible directly from the web, only from your script.

Another concern is using mysql. The old mysql extension is deprecated in php5 and was removed from php in version 7. You should use mysqli extension instead or look for a database wrapper layer like PDO.

Mcload
  • 288
  • 8
  • 18
  • 4
    Why is there any concern in using MySQL? How does the choice between mysql_*, mysqli_* and PDO relate to the question of securely saving the credentials? – Nico Haase Feb 08 '18 at 16:23