Das leidige mit Konfigdateien für PHP und Zugangsdaten für die DB
Immer wieder stolpere ich auf Servern oder in diversen Sourcode-Versionsverwaltungen wie git oder svn über hart eincodierte Zugangsdaten zu Datenbankservern oder sogar zu FTP-Servern. Auch in meinen ersten Projekten hat es sowas gegeben. Aber da hab ich noch keine Versionsverwaltung benutzt. Im Laufe der Jahre mit PHP-Projekten habe ich mir eine Aufteilung der Konfigdateien angewöhnt, die meinen Sicherheitsanforderungen stand hält und gleichzeitig die Passwörter aus irgendwelchen Repositorys raushält. Dies möchte ich hier mal als Anregung für die diversen Frischling-Programierer oder als Denkanstoß für einige alte Hasen vorstellen.
Der Grundgedanke dabei ist folgender. Ich benötige immer wieder Konfigurationseinstellungen, die sich je nach Projekt unterscheiden. Aber es gibt auch immer wieder Files, die ich in jedem Projekt verwende und die auch bei jedem Script eingebunden werden.
Als erstes gibt es da die global.php. Dieser File befindet sich im Web-Hauptverzeichnis des Projekts. Die Datei enthält Definitionen von Konstanten und Includes von PHP-Files, die immer benötigt werden.
Als erstes definiere ich WEB_ROOT. Damit haben alle anderen Scripte unabhängig davon in welchem Verzeichnis sie sich befinden eine Konstante mit dem Root-Verzeichnis des Projekts. Da __FILE__ sich immer auf das Script "global.php" bezieht, kommt auch der richtige Pfad dabei raus, wenn ich die global.php z.B. aus einem Unterverzeichnis als "../../global.php" includieren muss. Wie zu sehen ist, kann ich diese Datei getrost in ein neues Projekt kopieren, ohne etwas zu ändern.
In der untersten Zeile sieht man den nächsten Step. Es wird eine Datei config.php eingebunden. In jedem Projekt benötige ich Einstellungen, die es in einem anderen nicht gibt. Dies könnte z.B. der Pfad zu einem Datenverzeichnis sein.
In der Datei config.php habe ich ALLE Konfigurationseinstellungen für mein Projekt hinterlegt, die ich benötige. Aber wichtig dabei ist, das es sich dabei um DEFAULT-Einstellungen handelt. Vor allem die DB-Zugangsdaten sind dort ganz deutlich nur ein Beispiel, welches aber funktionieren würde wenn man sich auf so unsichere Zugangsdaten einlassen würde. Mit DATA_DIR definiere ich z.B. eine Defaultkonfig für ein Datenverzeichnis ausserhalb des Projektverzeichnisses. Einige Files will man nunmal nicht im DOCUMENT_ROOT des Webservers liegen haben. Mit DEFAULT_IMAGE_WIDTH ist auch noch ein Beispiel enthalten, welches ich benötige, um Vorschaubilder zu skallieren. Dadurch, dass hier alle notwendigen Konfigvariablen initalisiert werden, hab ich später keinen Ärger mit Fehlermeldungen, weil irgend ein Wert nicht gesetzt ist.
Die Magie der Datei ist die if-Anweisung. Es wird gecheckt, ob sich eine Datei namens .htconfig.php im WEB_ROOT befinden. Wenn dies der Fall ist, wird sie importiert. Der Dateiname ist ganz bewust gewählt. Dateien mit einem "." am Anfang sind unter Linux versteckte Dateien. Aber am wichtigsten ist mir dabei, dass in einem Apache-Webserver per Default Dateien, die mit ".ht" anfangen, nicht ausgeliefert werden. Dies ist ein Schutzmechanismuss, der auch die ".htaccess" Dateien vor dem Download schützt. PHP und Apache haben bei einem unvorsichtigen Admin oder auch unter bestimmten Fehlerbildern leider die Angewohnheit die Scriptdateien ungeparst auszuliefern. Ist der Webserver also nicht sauber konfiguriert, würde ein Angreifer die Zugangsdaten im Klartext sehen. Dies Problem stellt sich nicht, wenn man die Zugangsdaten in der ".htconfig.php" versteckt.
In der ".htconfig.php" können nun alle Variablen aus der "config.php" mit den richtigen Werten überschrieben werden. Werte, die ich nicht benötige, können einfach übersprungen werden.
Um den Bogen zu git und Subversion wieder zu schliessen, sei jetzt noch erwähnt, dass die Datei ".htconfig.php" nicht mit in die Versionsverwaltung übertragen werden. Bei git steht sie dazu einfach in der Datei ".gitignore" und bei Subversion in der ".svnignore".
Als Goodie kommt dabei auch noch heraus, dass ich eine neue Softwareversion jederzeit im Webverzeichnis entpacken kann. Da in diesen Archiven die ".htconfig.php" auch nicht enthalten ist, wird auch meine Konfig nicht überschrieben.
So. Und wer bis hierhin aufgepasst hat, wird sich jetzt evtl. noch über die Konstante CONFIG_OK wundern. Dies ist ein weiterer Sicherheitsmechanismuss für die Scripte. Habe ich in einer PHP-Datei nur eine Klasse definiert, stört es mich nicht wenn diese Datei von einem Browser aufgerufen wird. Aber es gibt auch Dateien, die nicht ohne bestimmte Vorraussetzungen aufgerufen werden dürfen. Diese schützte ich einfach direkt am dateianfang wie folgt...
Der Grundgedanke dabei ist folgender. Ich benötige immer wieder Konfigurationseinstellungen, die sich je nach Projekt unterscheiden. Aber es gibt auch immer wieder Files, die ich in jedem Projekt verwende und die auch bei jedem Script eingebunden werden.
Als erstes gibt es da die global.php. Dieser File befindet sich im Web-Hauptverzeichnis des Projekts. Die Datei enthält Definitionen von Konstanten und Includes von PHP-Files, die immer benötigt werden.
<?php
// global.php
define('WEB_ROOT',dirname(__FILE__));
require_once(WEB_ROOT . '/lib/class.DieIchImmerBrauche.php');
require_once(WEB_ROOT . '/lib/class.Database.php');
require_once(WEB_ROOT . '/config.php');
?>
Als erstes definiere ich WEB_ROOT. Damit haben alle anderen Scripte unabhängig davon in welchem Verzeichnis sie sich befinden eine Konstante mit dem Root-Verzeichnis des Projekts. Da __FILE__ sich immer auf das Script "global.php" bezieht, kommt auch der richtige Pfad dabei raus, wenn ich die global.php z.B. aus einem Unterverzeichnis als "../../global.php" includieren muss. Wie zu sehen ist, kann ich diese Datei getrost in ein neues Projekt kopieren, ohne etwas zu ändern.
In der untersten Zeile sieht man den nächsten Step. Es wird eine Datei config.php eingebunden. In jedem Projekt benötige ich Einstellungen, die es in einem anderen nicht gibt. Dies könnte z.B. der Pfad zu einem Datenverzeichnis sein.
<?php
// config.php
$MYSQL_HOST = "127.0.0.1";
$MYSQL_USER = "demo";
$MYSQL_PASS = "demo";
$MYSQL_NAME = "demo";
$DATA_DIR = WEB_ROOT . '/../data/';
$DEFAULT_IMAGE_WIDTH = 170;
if( is_file(WEB_ROOT . '/.htconfig.php') ) {
include_once(WEB_ROOT . '/.htconfig.php');
}
define('CONFIG_OK',1)
?>
In der Datei config.php habe ich ALLE Konfigurationseinstellungen für mein Projekt hinterlegt, die ich benötige. Aber wichtig dabei ist, das es sich dabei um DEFAULT-Einstellungen handelt. Vor allem die DB-Zugangsdaten sind dort ganz deutlich nur ein Beispiel, welches aber funktionieren würde wenn man sich auf so unsichere Zugangsdaten einlassen würde. Mit DATA_DIR definiere ich z.B. eine Defaultkonfig für ein Datenverzeichnis ausserhalb des Projektverzeichnisses. Einige Files will man nunmal nicht im DOCUMENT_ROOT des Webservers liegen haben. Mit DEFAULT_IMAGE_WIDTH ist auch noch ein Beispiel enthalten, welches ich benötige, um Vorschaubilder zu skallieren. Dadurch, dass hier alle notwendigen Konfigvariablen initalisiert werden, hab ich später keinen Ärger mit Fehlermeldungen, weil irgend ein Wert nicht gesetzt ist.
Die Magie der Datei ist die if-Anweisung. Es wird gecheckt, ob sich eine Datei namens .htconfig.php im WEB_ROOT befinden. Wenn dies der Fall ist, wird sie importiert. Der Dateiname ist ganz bewust gewählt. Dateien mit einem "." am Anfang sind unter Linux versteckte Dateien. Aber am wichtigsten ist mir dabei, dass in einem Apache-Webserver per Default Dateien, die mit ".ht" anfangen, nicht ausgeliefert werden. Dies ist ein Schutzmechanismuss, der auch die ".htaccess" Dateien vor dem Download schützt. PHP und Apache haben bei einem unvorsichtigen Admin oder auch unter bestimmten Fehlerbildern leider die Angewohnheit die Scriptdateien ungeparst auszuliefern. Ist der Webserver also nicht sauber konfiguriert, würde ein Angreifer die Zugangsdaten im Klartext sehen. Dies Problem stellt sich nicht, wenn man die Zugangsdaten in der ".htconfig.php" versteckt.
<?php
// .htconfig.php
$MYSQL_USER = "appuser";
$MYSQL_PASS = "realpassword";
$MYSQL_NAME = "appdb";
?>
In der ".htconfig.php" können nun alle Variablen aus der "config.php" mit den richtigen Werten überschrieben werden. Werte, die ich nicht benötige, können einfach übersprungen werden.
Um den Bogen zu git und Subversion wieder zu schliessen, sei jetzt noch erwähnt, dass die Datei ".htconfig.php" nicht mit in die Versionsverwaltung übertragen werden. Bei git steht sie dazu einfach in der Datei ".gitignore" und bei Subversion in der ".svnignore".
Als Goodie kommt dabei auch noch heraus, dass ich eine neue Softwareversion jederzeit im Webverzeichnis entpacken kann. Da in diesen Archiven die ".htconfig.php" auch nicht enthalten ist, wird auch meine Konfig nicht überschrieben.
So. Und wer bis hierhin aufgepasst hat, wird sich jetzt evtl. noch über die Konstante CONFIG_OK wundern. Dies ist ein weiterer Sicherheitsmechanismuss für die Scripte. Habe ich in einer PHP-Datei nur eine Klasse definiert, stört es mich nicht wenn diese Datei von einem Browser aufgerufen wird. Aber es gibt auch Dateien, die nicht ohne bestimmte Vorraussetzungen aufgerufen werden dürfen. Diese schützte ich einfach direkt am dateianfang wie folgt...
<?php
// eine Datei die nicht vom Browser aufgerufen werden soll...
if( ! defined('CONFIG_OK') ) {
die('Du kommst hier nicht rein!');
}
[...]
?>
