Protect PostgreSQL database connection - php

Question

I'm currently working on a php/PostgreSQL/JQuery project, and I'm an absolute beginner in all of these domains. In Php, to connect to my database, best way I found was to include a php
script with user and password in all php scripts that need it, like this.
include('../scripts/pgconnect.php');
With pgconnect.php :
$conn_string = "dbname=mydb user=myuser password=mypass";
$db = pg_connect($conn_string);
if(!$db){
die("Connection à la base impossible -> " . pg_errormessage($db));}
I'm sure all of you security expert will laugh at this, so could you tell me what is the best way to keep user and pass out from prying eyes ?
I found on stack overflow an advice to use env variables, but I don't find it really secure.

Answer 1

PHP is a server-side language. That means that when the requested page is sent back to the client all PHP code is parsed and "removed". As long you're the only one being able to look into your files there is no fear.
Whether you store it in (env) variables or not won't make a single difference.
There's absolutely nothing wrong with this code ;)
Edit:
When you execute an SQL query however, you need to be careful. Often, you use user input (an URL or POST data) to set certain values in a query. For example:
$sql = 'SELECT * FROM `table` WHERE `id`=' . $_GET['id'];
The $_GET['id'] variable is set in the URL (index.php?id=4).
If they change the value 4 to a bit of SQL query, they can pretty much do everything with your database. This is called SQL injection. It's truly the biggest threat of web applications using a database.
There are multiple fixes.
Sanitize the input (make sure that the input doesn't contain SQL syntax)
Prepare statements
Now, I'm not familiar with PostgreSQL, but apparently the PHP module has the ability to send prepared statements. This allows you to send the query with the unknown values as question marks and send the values afterwards.
$sql = 'SELECT * FROM `table` WHERE `id`=?';
// send prepared statement
$value = $_GET['id'];
// send the value
This way the database can tell that the value is no query.
Like I said, I'm not familiar with PostgreSQL, but I'm sure there are some tutorials that will guide you all the way through!
Another edit:
Because I'm a nice guy, I found how to do it! You need to use the function pg_prepare() and pg_execute(). Like this:
// This is a name to allow the database to identify the prepared statement
$queryname = 'my_query';
// Setting up our query with "empty" values
$sql = "SELECT * FROM `table` WHERE `column`='$1' AND `column`='$2'";
// Setting our values to send afterwards
$values = array(
$_GET['first_value'], // The first value that will replace $1
$_GET['second_value'] // The second value that will replace $2
);
$result = pg_prepare($connection, $queryname, $sql); // Send the query to the database
$result = pg_execute($connection, $queryname, array($value)); // Send the values
Last edit (I swear):
If you decide to put your configuration variables in an extern file, lets say configuration.php, make sure that the file ends with the .php extension. If you use a different extension, people might be able to find it and see it in plain text. If the PHP extension is used, they won't be able to see anything because like I said, the PHP is parsed and removed.

Answer 2

I use environment variable to store db authentication information: that is, the host/user/password for the db are in SetEnv commands in the Apache configuration, which appear in $_SERVER.
Why do this?
Development and production environments need different values for these, so having the application read some sort of environment configuration is necessary.
The application code is in a source code repository, which is easily browseable... embedding authentication secrets into it would make those just as widely available.
Environment variables aren't the only solution: for example, including a file that sets up a configuration object of some sort will work too. But most people seem to evolve some system for having the configuration settings (and just the settings) in a single changeable point, separate from the code that uses those settings, which changes on a completely different schedule.