Verschleiern/verstecken von Variablen direkt im Quellcode

[Enrico]

Hallo,

ich verwende Swiftmailer, um E-Mails aus einem php-Skript zu verschicken.

Im Quellcode muss ich u.a. den Benutzername und das Passwort hinterlegen:

  
require_once 'PHP/SWIFTMAILER/swift_required.php';  
  
$transport = Swift_SmtpTransport::newInstance('send.one.com', 465, 'ssl')  
             ->setUsername('[e-mail]')  
             ->setPassword('Yggdrasil9');  

Passwörter im Klartext in einer Datei abzulegen ist aber bekannter weise absoluter Blödsinn.

Wie kann ich den Benutzernamen und das Passwort zuverlässig verschleiern oder, was noch besser wäre, vor Zugriffen und der Einsichtnahme von Außen abschotten?

Vielen Dank für eure Ratschläge.

Gruß,
Enrico

[hotti]

Hinterlege Credentials in einer Konfigurationsdatei. Falls der PHP-Parser mal streiken sollte, wird höchstens der Pfad zur Konfigurationsdatei sichtbar und diese Datei sollte außerhalb der DOCUMENT_ROOT liegen.

MfG

[Enrico]

Hallo hotti,

Hinterlege Credentials in einer Konfigurationsdatei

Du meinst, ich soll hier den Weg übers Parsen einer ini-Datei gehen?

diese Datei sollte außerhalb der DOCUMENT_ROOT liegen.

Also beispielsweise eine Ebene höher als die index.php/.html?

Wie definiere ich dann den Pfad?

Sorry, wenn ich hier dumm nachfrage, aber ich habe mich mit dieser Thematik noch nie befassen müssen.

Gruß,
Enrico

[hotti]

Hi,

Du meinst, ich soll hier den Weg übers Parsen einer ini-Datei gehen?

parse_ini_file ist doch ideal für sowas.

diese Datei sollte außerhalb der DOCUMENT_ROOT liegen.
Also beispielsweise eine Ebene höher als die index.php/.html?

Auf jeden Fall so, dass die ini nicht mit dem Browser erreichbar ist.

\ Machs gut (_)3

[Enrico]

Hallo hotti,

ich habe die ini-Daten jetzt wie folgt in eine php-Datei verpackt:

  
;<?php  
;die();  
;/*  
  
Username=...  
Password=...  
  
;*/  
;?>  

Sollte die Datei direkt im Browser aufgerufen werden, also mit Endung ".php", dann bricht die Anzeige sofort ab.

Ist das so ausreichend oder kann/soll ich die Datei noch weiter schützen/abschotten?

Das parsen über parse_ini_file geht dann mit relativer Pfadangabe einwandfrei.

Gruß,
Enrico

[M.]

Mahlzeit,

Sollte die Datei direkt im Browser aufgerufen werden, also mit Endung ".php", dann bricht die Anzeige sofort ab.

Wozu soll das gut sein? Hotti sagte doch, die muss ausserhalb des Docroot liegen. Also wie soll sie per Browser aufgerufen werden?

Ist das so ausreichend oder kann/soll ich die Datei noch weiter schützen/abschotten?

Nein. Wenn der Parser einen Fehler hat, wird die Datei im Klartext angezeigt.

Das parsen über parse_ini_file geht dann mit relativer Pfadangabe einwandfrei.

Geil, noch einfacher kannst du es einem Hacker kaum machen ;)

[Enrico]

Hallo M,

Hotti sagte doch, die muss ausserhalb des Docroot liegen

Das habe ich berücksichtigt.

Also wie soll sie per Browser aufgerufen werden?

Keine Ahnung, da ich mich mit dieser Materie bislang noch nicht befassen musste.
Deshalb habe ich auch gefragt.

Das parsen über parse_ini_file geht dann mit relativer Pfadangabe einwandfrei.
Geil, noch einfacher kannst du es einem Hacker kaum machen ;)

Aber ich muss doch den Pfad angeben, wie soll ich auf die sich außerhalb des Rootverzeichnisses befindliche Datei sonst zugreifen können?

Gruß,
Enrico

[hotti]

hi,

Aber ich muss doch den Pfad angeben, wie soll ich auf die sich außerhalb des Rootverzeichnisses befindliche Datei sonst zugreifen können?

Es gibt für Webanwendungen 3 Möglichkeiten der Pfadangabe:

1. bezogen auf den Authority-Part eines URI (z.B.: http://example.com/index.php oder /cfg.ini)
2. bezogen auf das Dateisystem
     2a) relativ (z.B.: cfg.ini)
     2b) absolut (z.B.: /home/user/boo/cfg.ini)

Übern Browser erreichbar ist (1) und (2a).

(_)3

[Enrico]

Hallo hotti,

danke für Deine Antwort, die mich aber leider nur insofern weiterbringt, als dass ich jetzt weiß, dass in meinem Fall nur ein absoluter Pfad dafür zu schützen scheint, die php-Datei, die die Anmeldedaten für Swiftmailer im ini-Format enthält, vor Zugriffen von Außen abzuriegeln (wenn ich Dich richtig verstanden habe).

M meinte sinngemäß, dass ein relativer Pfad eine gute Hilfestellung zum Hacken wäre.

Wie soll ich aber einen absoluten Pfad definieren, der eine Ebene Höher als das Rootverzeichnis ist? Ich muss hier ja mit einer relativen Angabe arbeiten, oder sehe ich das falsch?

Wie sieht es mit folgendem Ansatz, den ich in über eine Google-Suche gefunden habe, aus?

  
$path_to_dir_above_root = $_SERVER['DOCUMENT_ROOT'] . '/../';  

Liefert er mir das gewünschte Resultat?
Wie sieht es hier mit der Sicherheit aus, wenn ich den Code verwende?

Gruß,
Enrico

[dedlfix]

Tach!

danke für Deine Antwort, die mich aber leider nur insofern weiterbringt, als dass ich jetzt weiß, dass in meinem Fall nur ein absoluter Pfad dafür zu schützen scheint, die php-Datei, die die Anmeldedaten für Swiftmailer im ini-Format enthält, vor Zugriffen von Außen abzuriegeln (wenn ich Dich richtig verstanden habe).

Hottis Aufzählung ist unvollständig. Selbstverständlich ist ein relativer Dateipfad raus aus dem DocumentRoot genauso sicher oder unsicher wie ein absoluter Pfad. In keinem Fall sind beide aus dem Web erreichbar (vorausgesetzt, dass sie nicht in irgendeinem anderen Docroot zu liegen kommen).

M meinte sinngemäß, dass ein relativer Pfad eine gute Hilfestellung zum Hacken wäre.

Ich vermute, er hat da was anderes verstanden als was du meintest.

Wie soll ich aber einen absoluten Pfad definieren, der eine Ebene Höher als das Rootverzeichnis ist? Ich muss hier ja mit einer relativen Angabe arbeiten, oder sehe ich das falsch?

Nein, das ist soweit richtig.

Wie sieht es mit folgendem Ansatz, den ich in über eine Google-Suche gefunden habe, aus?

$path_to_dir_above_root = $_SERVER['DOCUMENT_ROOT'] . '/../';

> Liefert er mir das gewünschte Resultat?  
  
Ja, aber auch '../' wenn das aktuelle Verzeichnis das DocumentRoot ist.  
  

> Wie sieht es hier mit der Sicherheit aus, wenn ich den Code verwende?  
  
Alles was nicht im DocumentRoot liegt ist nicht direkt vom Web aus ansprechbar. Die Art der Referenzierung der Dateinamen übers Dateisystem spielt dabei keine Rolle.  
  
  
dedlfix.

[Enrico]

Hallo dedlfix,

$path_to_dir_above_root = $_SERVER['DOCUMENT_ROOT'] . '/../';
Liefert er mir das gewünschte Resultat?

Ja, aber auch '../' wenn das aktuelle Verzeichnis das DocumentRoot ist.

Wunderbar, funktionieren tut es und wenn ich hiermit sicher sein kann, dass niemand Zugriff auf dieses "Verzeichnis" hat, dann ist ja alles bestens. :-)

Danke Dir!

Gruß,
Enrico

[hotti]

Moin,

Hottis Aufzählung ist unvollständig.

Stimmt. Es gibt 4 Möglichkeiten zur Pfadangabe:

1. bezogen auf den Authority-Part eines URI relativ und absolut
2. bezogen auf das Dateisystem relativ und absolut

MfG

[dedlfix]

Tach!

Wie kann ich den Benutzernamen und das Passwort zuverlässig verschleiern oder, was noch besser wäre, vor Zugriffen und der Einsichtnahme von Außen abschotten?

Gar nicht mit hunderpozentiger Sicherheit. Du kannst sie in der PHP-Datei lassen. Alles andere bringt nur marginale Vorteile.

Wenn jemand Code auf deinem Rechner ausführen kann, ist nichts zu retten. Du musst ja zum verschlüsselten Passwort auch wieder die Entschlüsslung im Code stehen haben, wozu du einen Key oder ein Passwort brauchst, das du nicht verschlüsseln kannst. (Also, das geht schon, aber dann geht die Kette weiter und an dessen Ende steht immer in unverschlüsselter Wert.) Verschlüsslung bringt also nichts, außer Arbeit viel Arbeit für dich und unter Umständen nur ganz ganz wenig für den potentiellen Entwender.

Dann bleibt noch das Szenario übrig, dass der Webserver fehlkonfiguriert ist und PHP-Code unabgearbeitet rausgibt. Das sollte zwar recht schnell auffallen, weil dann mit Sicherheit ziemlich viel nicht mehr läuft, dagegen hilft aber, (PHP-)Code in eine Datei auszulagern, die nicht ausgeliefert werden kann. Also Dateien, die außerhalb des DocumentRoot abgelegt sind. Und das kann dann ruhig PHP-Code bleiben, muss nicht irgendein anderes Dateiformat werden. Allerdings ist das DocumentRoot ebenfalls (fehl)konfigurierbar.

Wenn man mal davon ausgeht, dass man bezüglich des DocumentRoot keine Fehler in den Server konfiguriert, ist die Ablage außerhalb des DocumentRoot eine recht effektive und effiziente Art, die Daten wenigstens einigermaßen aus der Schusslinie zu nehmen. Wenn das ein Server ist, der mehrere Projekte hostet, dann kommen noch die Berechtigungsvergaben ins Spiel, damit die benachbachbarten Projekte nicht ohne Hürde an die Daten kommen.

dedlfix.

[hotti]

hi,

Dann bleibt noch das Szenario übrig, dass der Webserver fehlkonfiguriert ist und PHP-Code unabgearbeitet rausgibt. Das sollte zwar recht schnell auffallen, weil dann mit Sicherheit ziemlich viel nicht mehr läuft, dagegen hilft aber, (PHP-)Code in eine Datei auszulagern, die nicht ausgeliefert werden kann. Also Dateien, die außerhalb des DocumentRoot abgelegt sind. Und das kann dann ruhig PHP-Code bleiben, muss nicht irgendein anderes Dateiformat werden. Allerdings ist das DocumentRoot ebenfalls (fehl)konfigurierbar.

Vorschlag: Alle Libraries aus dem DocRoot rausnehmen und nur noch eine PHP-Datei vorhalten, die vom Webserver geparst wird.

?
   ?
  ?
 \_/7

[Auge]

Hallo

Dann bleibt noch das Szenario übrig, dass der Webserver fehlkonfiguriert ist und PHP-Code unabgearbeitet rausgibt. Das sollte zwar recht schnell auffallen, weil dann mit Sicherheit ziemlich viel nicht mehr läuft, dagegen hilft aber, (PHP-)Code in eine Datei auszulagern, die nicht ausgeliefert werden kann. Also Dateien, die außerhalb des DocumentRoot abgelegt sind. Und das kann dann ruhig PHP-Code bleiben, muss nicht irgendein anderes Dateiformat werden. Allerdings ist das DocumentRoot ebenfalls (fehl)konfigurierbar.

Vorschlag: Alle Libraries aus dem DocRoot rausnehmen und nur noch eine PHP-Datei vorhalten, die vom Webserver geparst wird.

Nur mal so. Wenn man nicht alles in einer Ressource, typischerweise mit einem Haufen von URL-Parametern, die bestimmen, was ausgegeben wird, abhandeln will, hat man für jede Seite eine zu parsende PHP-Datei. Ich persönlich finde das übersichtlicher, aber lassen wir das Geschmackssache sein. Daher würden bei mir jene Dateien, die Zugangsdaten jeglicher Coleur enthalten, außerhalb des Docroot oder ersatzweise in einem per .htaccess gesicherten Verzeichnis [1] landen.

<nitpicking>Außerdem werden natürlich auch die eingebundenen, außerhalb des Docroot liegenden, PHP-Dateien, wenn auch nicht durch den Webserver, sondern durch den durch ihn aufgerufenen PHP-Interpreter, geparst.</nitpicking>

?
   ?
  ?
\_/7

Joah, meiner ist mittlerweile kalt.

[1] Es soll ja vereinzelt immer noch Hoster geben, bei denen man keinen Zugriff auf Verzeichnisse außerhalb des Docroot hat. Man sollte denen aber auf die Füße treten oder über kurz oder lang den Rücken kehren.

Tschö, Auge