Sensible Daten in PHP-Dateien

Impressum | Werbung

Geizhals » Forum » Programmierung »

Sensible Daten in PHP-Dateien - sicher? (14 Beiträge, 263 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

auslesen via browser geht nicht, wenn es php code ist.
wenn es normale datein sind wo der text in plaintext steht, kann man es genaus auslesen wie als wäre es .html oder was auch immer.

bei php code übersetzt der server den syntax - der enduser bekommt davon nix mit.
sensible daten wären aber in einer DB besser aufgehoben

nico

„Worüber man nicht sprechen kann, darüber soll man schweigen.“

Auch wenn der PHP Sourcecode nicht ausgeliefert wird, weil er vorher geparst wird, würde ich sensible Dateien mit einem .htaccess schützen, und zwar so, dass bei direktem aufruf IMMER ein 404 Fehler ausgeliefert wird, als würde es die Datei nicht geben.

Grund: Wenn jemand am Webserver (Apache) herumschraubt, und das PHP Modul kurz ausfällt, wird der Code nicht mehr geparst, und direkt ausgegeben - dann könnte jemand den sensiblen Inhalt sehen. Mit meiner Methode würde er in jedem Fall einen 404er Fehler bekommen.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.3 - Firefox Erweiterung für Geizhals User

Eine bessere Möglichkeit wäre noch, die sensiblen Daten in einem Verzeichnis zu lagern, auf das der Browsern gar keinen Zugriff hat (von extern - über den Apachen).

Dort wo du es brauchst, machst du einfach einen include mit absolutem Pfad, wo die Datei im Filesystem eben liegt.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.3 - Firefox Erweiterung für Geizhals User

05.10.2007, 17:15 Uhr - Editiert von Dr. Watson, alte Version: hier

Wenn man einen Teil(Programmteile, Daten u.ä) mit include in php einbindet und der Parser versagt, gibt er denoch nicht diese Datei dann auch im Browser aus.

sagen wir.:

../scripte/
liegt ausserhalb des Apachen und ich include von eine Datei secure.php
würde bei Parser Fehler nicht diese dann einfach an den Browser in plain text ebenfalls gejagt werden?

sagen wir die secure enthält sensiblen Code und ein oder andere sensible statische Variable.

Ich trau den Scriptzeugs überhaupt nicht.

Wenn man einen Teil(Programmteile, Daten u.ä) mit include in php einbindet und
der Parser versagt, gibt er denoch nicht diese Datei dann auch im Browser aus.

Es geht nicht darum, dass der parser versagt, sondern dass der Webserver den Content gar nicht erst zum parser schickt, sondern diesen als statisch betrachtet, und an den Client ausliefert.

../scripte/
liegt ausserhalb des Apachen und ich include von eine Datei secure.php
würde bei Parser Fehler nicht diese dann einfach an den Browser in plain text
ebenfalls gejagt werden?

Der Client würde zwar das "include("../scripte/foobar.php"); sehen, nicht jedoch den Inhalt des Skriptes - das Include wird ja nicht ausgeführt, wenn der parser nicht läuft - User sieht also keine sensiblen daten.
--
DiTech postete:
Sie haben offensichtlich 7mal mit dem Goldadler positive Erfahrung gemacht. Bei dieser Menge an Glück sollten Sie Lotto spielen.

GHF Watcher 1.3 - Firefox Erweiterung für Geizhals User

intelligent.

nico

„Worüber man nicht sprechen kann, darüber soll man schweigen.“

also, ich persönlich hab in meinem webroot, also http://domain.xy/ meistens nur die dateien liegen, auf die der benutzer auch wirklich zugreift. alles, was er nicht sehen soll, also konfigurationsdateien, klassen, was auch immer - auch wenn ers eigentlich nicht sehen kann, wenn ers direkt aufruft, liegen außerhalb des webroots.

die konfigurationsdateien, klassen, templates etc. kommen alle in folder die überm webroot liegen. und in die kann der browser nicht, egal was kommt - auch wenn php mal aus irgendeinem grund ausfallen sollte, und der browser den php-quellcode als klartext ausgibt.

dateien, die nicht jeder user downloaden darf (also z.b. ein pdf-file, das nur ein bestimmter eingeloggter benutzer bekommt), liegen bei mir ebenfalls außerhalb des webroots. wenn der user dann dieses file haben will, dann wird das direkt rauskopiert. das geht, indem du per header()-funktion den dateityp angibst, und dann die daten an sich einfach direkt (per echo zb. stück für stück rausschreibst). solang du nicht extra performante apps baust, ist das eigentlich kein problem.

Möglichkeiten gibt es unzählige; du brauchst nur irgend ein Script auf dem Server haben das sich irgendwie dazu überreden läßt die Datei einzulesen und auszugeben. Das kann dir dann auch Dateien ausserhalb des Webroots ziehen (wenn dein Webserver Prozess Leserechte dazu hat).

Ich benutze z.B. auf meinem Webhost, der keinen Shell-Zugang bietet, ein einfaches CGI-Script das mein gesamtes Home-Verzeichnis in ein tar packt, um Backups zu machen. Das Script lade ich nur auf den Server wenn ich das Backup auch tatsächlich anfertige, und lösche es direkt nachdem ich es ausführe (also während ich das tar-Archiv herunterlade ist das Script an sich schon gar nicht mehr da).

Aber prinzipiell zeigt es doch was theoretisch möglich ist - eine einzige Webapp mit Sicherheitslücke reicht aus um den gesamten Datenbestand meines Servers zu stehlen oder gar zu kompromittieren.

Das Problem ist halt, daß alle Daten, auf die der Webserver prinzipiell Zugriff hat, potentiell nicht sicher sind - darunter fallen in meinem Fall auch Mails weil bei meinem Angebot auch ein Webmailinterface dabei ist und die Mails nicht auf einem separaten, sondern direkt auf meinem Webspace gespeichert werden (Billiganbieter halt).

Sensible Daten außerhalb des Webroots lagern ist das Minimum was du tun kannst um eine Grundsicherheit zu gewährleisten - du schließt damit aus daß aufgrund eines Konfigurationsfehlers jemand doch auf ganz normalem Weg per URL an die Daten kommen kann. Aber dir sollte bewusst sein, daß auch das keine absolute Sicherheit ist, sondern du sehr vorsichtig sein solltest, welche CGI-Scripte / PHP-Programme / whatever du auf deinem Server installierst und laufen läßt.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung