Ich mag es nicht, sitewide crypto keys und DB access information unter document_root zu speichern, also benutzte ich Apache SetEnv und php.ini Dateien unter conf.d, um diese von der Codebasis zu trennen. Die große Frage ist, welche ist besser? Inside-Umgebungsvariablen unter Apache vhost-Dateien ( SetEnv SITEKEY 'oinkoink!' ) oder innerhalb conf.d / xxx.ini-Dateien ( db_pass="oink?" )? Vielleicht etwas anderes?
PROS n CONS:
SetEnv:
+ Gespeichert außerhalb von DOCUMENT_ROOT
+ Nur der angegebene vhost hat Zugriff auf
-Visible mit PHPINFO () - Hacker benötigt direkten Zugriff / Upload Exploit zu Dateien
get_cfg_var:
+ Gespeichert außerhalb von DOCUMENT_ROOT
+ Nicht sichtbar mit PHPINFO ()
- (SEHR SCHLECHT) Alle definierten Ini-Variablen sind enthalten, so dass jeder vhost sie über (ini_get_all) abfragen kann, also in einer freigegebenen vhost-Umgebung nicht verwendbar ist.
Solange sich * .ini und SetEnv außerhalb des Webstamms (Dokumentenstammverzeichnis) befinden, spielt dies keine Rolle. Wählen Sie einfach, was Sie bevorzugen. Ich mag SetEnv, aber es ist wirklich nur persönliche Vorliebe. Es macht mehr Sinn, SetEnv zu verwenden, da die Variablen in _SERVER eingefügt werden. Mit der .ini finde ich es sinnvoller, Initialisierungseinstellungen für den Code zu belassen.
Das Speichern unter dem Stammverzeichnis ist keine gute Idee, um den Zugriff auf möglicherweise sichere Daten zu verhindern.
Beachten Sie, dass phpinfo() alle Servervariablen auflistet, die gesetzt sind. Seien Sie deshalb sehr vorsichtig.
Schließlich, wenn Sie Dateien einbinden, stellen Sie sicher, dass Sie nicht die vom Benutzer eingestellte kostenlose ../../ irgendwie erlauben, oder sie haben Zugang zu potenziell sicheren Dateien (sogar einschließlich /etc/passwd !)
Ich denke Ihre Hauptfrage ist "wie sicher". Nun, das ist wahrscheinlich ungefähr so sicher, wie Sie bekommen können, ohne größere Kopfschmerzen zu verursachen. Der PHP-Code hat Zugriff auf diese Variablen. Wenn Sie sie also ausdrucken, sind sie gut sichtbar. Es hängt also davon ab, wie sicher Ihre Codebasis ist. Es könnte möglich sein, LDAP mit MySQL zu verwenden, aber das klingt wie ein großer Schmerz.
Es ist üblich, nicht-öffentliche Dateien außerhalb von document_root zu speichern. Ein typisches Layout könnte dies sein:
%Vor%Speichern Sie Ihre PHP-Dateien in documentRoot und alle nicht öffentlichen Dateien in nonPublicFiles . documentRoot wäre der Apache document_root des vHost. Da nonPublicFiles draußen ist, antwortet Apache nicht auf die Anfrage.
Bei der Erkennung von Sicherheit sind SetEnv oder *. ini gleichwertig: Falls jemand Rechte zur Ausführung von beliebigem PHP-Code erhält, bieten beide Möglichkeiten sinnvolle Informationen Code.
Ich würde die Methode SetEnv und * .ini bevorzugen, da Apache diese Details nicht selbst offenlegt. Ein Skript ist erforderlich.
Eine Fehlkonfiguration kann den Inhalt von nonPublicFiles auch ohne ein Skript offen legen.
Wenn Sie nonPublicFiles verwenden, bereiten Sie im Vorfeld ein Skript vor, das prüft, ob alles ordnungsgemäß eingerichtet ist, und eine E-Mail weiterleiten, falls es Probleme gibt. Wahrscheinlich nennen Sie es mit CRON.