Wie sicher sind *.php und *.inc Dateien?

[Mastershrimp]

Heyho!

Was mich schon seit längerem beschäftigt, ist das Problem, wie ich mit Passwörtern innerhalb einer PHP-Datei umgehen soll...
Datenbank-Zugänge und sonstige Passwörter sind ja normalerweise in der PHP-Datei selber erwähnt (es sei denn, man macht irgendwas mit Usern).

Kann man PHP-Dateien nicht mittels den PHP-eigenen Funktionen einfach auslesen und dann nachschauen, wie das Passwort lautet? Oder wird dann nur der auszugebene HTML-Inhalt ausgelesen und der eigentliche PHP-Code bleibt geheim?

Noch einfacher geht's mit Include-Dateien. Die muss man nur im Browser aufrufen und schon hat man den kompletten Inhalt.

Wo soll ich Passwörter eintragen? Ich hätte gerne eine globale Include-Datei mit all den Zugangsdaten, aber die kann dann ja jeder lesen, der die URL der Datei kennt....

Was würdet ihr mir raten?

Chapeau! ;)

Mastershrimp

[Bio]

Sup!

Ich wuerde die Zugriffsrechte fuer wichtige Dateien so setzen, dass sie niemand unautorisiertes lesen kann und den Webserver so konfigurieren, dass er direkte Zugriffe auf .inc-Dateien nicht zulaesst, nie den Quellcode von .php-Dateien rausrueckt etc..

Sicher gibt's da tausende von HowTos fuer.

Gruesse,

Bio

[Mastershrimp]

Ich wuerde die Zugriffsrechte fuer wichtige Dateien so setzen, dass sie niemand unautorisiertes lesen kann und den Webserver so konfigurieren, dass er direkte Zugriffe auf .inc-Dateien nicht zulaesst, nie den Quellcode von .php-Dateien rausrueckt etc..

Leider habe ich keine Zugriffsrechte auf den Server. Bin bei all-inkl.

Bin ich also hoffnungslos ungeschützt?

Chapeau! ;)

Mastershrimp

[Sven Rautenberg]

Moin!

Wo soll ich Passwörter eintragen? Ich hätte gerne eine globale Include-Datei mit all den Zugangsdaten, aber die kann dann ja jeder lesen, der die URL der Datei kennt....

Was würdet ihr mir raten?

Das tolle bei Dateien mit der Endung ".php" ist, dass sie unter normalen Umständen niemals als Quelltext ausgeliefert werden. Dort im PHP-Code also Passwörter an Variablen zuzuweisen ist hinsichtlich der Sicherheit gut.

Dummerweise sind solche Include-Dateien grundsätzlich so zu programmieren, wie ein komplettes Skript. Wird darin beispielsweise include() eingesetzt, in dem eine Variable vorkommt, ist gleichzeitig register_globals gesetzt und allow_url_fopen auch auf on, kann man die einzelne Include-Datei mit URL-Parametern aufrufen und Schaden anrichten.

Die Abhilfe ist eine Dateiendung wie ".inc", welche üblicherweise nicht durch den PHP-Parser gejagt wird, aber eben ohne weitere Vorkehrungen im Quelltext ausgeliefert würde, sofern man ihre URL kennt.

Es hängt stark vom Provider ab. Manche sperren den HTTP-Zugriff auf ".inc".

Am schlauesten erscheint mir, sich die Standard-Konfiguration des Apache-Webservers zunutze zu machen: Der Zugriff auf Dateien, deren Name mit ".ht" BEGINNT (nicht endet), ist normal nicht erlaubt. Auf diese Weise sind die typischen Dateien ".htaccess", ".htusers", ".htpasswd" etc. geschützt.

Es spricht nichts dagegen (und viel dafür), sich diesen Schutz zunutze zu machen und seine geheimen PHP-Passwort-Includes als ".htphpinc.php" abzulegen.

Nachteil: Dateien, die mit einem Punkt beginnen, werden von Unix-Betriebssystemen gerne als "versteckt" behandelt, tauchen in einem normalen Directory-Listing, wie man es auch mit FTP erhalten würde, nicht auf. Das könnte einen also eventuell hindern, wenn man seinen FTP-Client nicht im Griff hat. :)

- Sven Rautenberg

[Mastershrimp]

Heyho!

Es spricht nichts dagegen (und viel dafür), sich diesen Schutz zunutze zu machen und seine geheimen PHP-Passwort-Includes als ".htphpinc.php" abzulegen.

Nachteil: Dateien, die mit einem Punkt beginnen, werden von Unix-Betriebssystemen gerne als "versteckt" behandelt, tauchen in einem normalen Directory-Listing, wie man es auch mit FTP erhalten würde, nicht auf. Das könnte einen also eventuell hindern, wenn man seinen FTP-Client nicht im Griff hat. :)

Vielen Dank für diesen Tipp! Der sollte bei mir problemlos klappen, da ich mit meinem FTP-Client auch die .htaccess problemlos anzeigen kann.

Gibts da sonst noch was, das ich beachten sollte? Oder kann man dieses Workaround bedenkenlos verwenden?

Chapeau! ;)

Mastershrimp

[Tom]

Hello,

Vielen Dank für diesen Tipp! Der sollte bei mir problemlos klappen, da ich mit meinem FTP-Client auch die .htaccess problemlos anzeigen kann.

Hast Du ein Verzeichnis zur Verfügung, das außerhalb der Document Root liegt? Manche Provider denken da ja mit!

Dann solltest Du die gesamten Scripte dort unterbringen. Mit normalem Request per HTTP sind sie dann nicht mehr ereichbar. Der Webserver sollte natürlich Lesezugriff darauf haben.

Anderenfalls würde ich auf jeden Fall ein eigenes Verzeichnis für Scripte anlegen, dass dann mit .htaccess gegen HTTP-Requests gesperrt wird.

Auf jeden Fall würde ich die PW-Dateien per FTP-Client oder SSH-Zugang gegen Beschreiben schützen auf OS-Ebene.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Mastershrimp]

Heyho!

Hast Du ein Verzeichnis zur Verfügung, das außerhalb der Document Root liegt? Manche Provider denken da ja mit!

Nicht dass ich wüsste....

Was meinst du mit "schützen"? CHMOD?

Habe sämtliche PHP-Scripts in einem Ordner. Wenn ich den nun mit dieser htaccess-Variante schütze, kann sich das auf die Funktionsweise des Scripts auswirken?

Kann man theoretisch ein ungeschütztes PHP-Script von einer anderen Webseite auslesen? Quasi Cross-Site-Auslesing ;) ?

Weil wenn man das eh nicht kann, dann lohnt sich der Aufwand nicht.

Fragen über Fragen, ich hoffe mir kann sie jmd beantworten.

Danke schonmal an alle bisherigen und zukünftigen Poster!

Chapeau! ;)

Mastershrimp

[Shaddai]

Guten Morgen,

Noch einfacher geht's mit Include-Dateien. Die muss man nur im Browser aufrufen und schon hat man den kompletten Inhalt.

Die Zeilen

<filesmatch ".(inc|dat|etc)?$">
deny from all
</filesmatch>

in der .htaccess dürften dies zuverlässig unterbinden.

Gruß,
Shaddai

[Mastershrimp]

Heyho!

Die Zeilen

<filesmatch ".(inc|dat|etc)?$">
deny from all
</filesmatch>

in der .htaccess dürften dies zuverlässig unterbinden.

Welche Zugriffe werden hierbei genau unterbunden? Alle? Also auch meine eigenen? Muss die htaccess-Datei mit diesen Zeilen im selben Ordner sein, oder kann ich auch die Datei des Hauptverzeichnis benutzen? Sollte sich dann ja auch auf alle Unterordner auswirken, oder?

Danke für den Tipp!

Habs erstmal so gelöst, wie Sven R. meinte, aber vllt überleg ichs mir nochmal. Deine Lösung ist ja wesentlich "eleganter" ;)

Chapeau! ;)

Mastershrimp

[Tom]

Hello,

<filesmatch ".(inc|dat|etc)?$">
deny from all
</filesmatch>

in der .htaccess dürften dies zuverlässig unterbinden.

Welche Zugriffe werden hierbei genau unterbunden? Alle? Also auch meine eigenen?

Du hast ja gar keinen eigenen Zugriffe. Du beauftragst den Webserver per HTTP-Request, einen Zugriff für dich durchzuführen. Es gibt also nur Zugriffe des Webservers, die per HTTP veranlasst werden, oder die (über das lokale System) per Script veranlasst werden.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Mastershrimp]

Heyho!

Du hast ja gar keinen eigenen Zugriffe. Du beauftragst den Webserver per HTTP-Request, einen Zugriff für dich durchzuführen. Es gibt also nur Zugriffe des Webservers, die per HTTP veranlasst werden, oder die (über das lokale System) per Script veranlasst werden.

Mja. Ok. Schlecht formuliert. Werden denn nun alle oder nur die aus dem lokalen System unterbunden?

Chapeau! ;)

Mastershrimp

[wahsaga]

hi,

Mja. Ok. Schlecht formuliert. Werden denn nun alle oder nur die aus dem lokalen System unterbunden?

weder noch - genau andersherum.

die über HTTP werden unterbunden - die über's lokale dateisystem sind weiterhin möglich (sofern die dateirechte es erlauben).

gruß,
wahsaga

[Mastershrimp]

Heyho!

weder noch - genau andersherum.

die über HTTP werden unterbunden - die über's lokale dateisystem sind weiterhin möglich (sofern die dateirechte es erlauben).

Sorry. Hab mich irgendwie "verdacht" ;)
Ich meinte mit "lokalem System" auf jeden Fall den Zugriff über HTTP. Habs halt nur genau falschherum formuliert...

Wenn ein Script auf einem Server eine (auch auf diesem Server befindliche) Datei per absoluter URL anspricht, gilt das dann immer noch als lokaler Zugriff?

Chapeau! ;)

Mastershrimp

[Sven Rautenberg]

Moin!

Wenn ein Script auf einem Server eine (auch auf diesem Server befindliche) Datei per absoluter URL anspricht, gilt das dann immer noch als lokaler Zugriff?

Wenn der Zugriff über HTTP erfolgt, gelten die Zugriffsbeschränkungen von .htaccess und der übergeordneten Konfigurationsdatei des Servers.

Wenn der Zugriff über das Dateisystem erfolgt, gelten die Beschränkungen des Dateisystems.

Die allermeisten Zugriffe von PHP erfolgen über das Dateisystem, beispielsweise Includes. Dort mußt du explizit "http" und die Domain in der Adresse angeben, damit du einen HTTP-Zugriff auf den Server machst.

- Sven Rautenberg

[Tom]

Hello,

Du hast ja gar keinen eigenen Zugriffe. Du beauftragst den Webserver per HTTP-Request, einen Zugriff für dich durchzuführen. Es gibt also nur Zugriffe des Webservers, die per HTTP veranlasst werden, oder die (über das lokale System) per Script veranlasst werden.

Mja. Ok. Schlecht formuliert. Werden denn nun alle oder nur die aus dem lokalen System unterbunden?

Wir setzen einfach mal voraus:
Ein Webserver hat immer nur direkten Zugriff auf das lokale Filesystem seiner Maschine. Kommt die Aufforderung an ihn nun von "innen", dann sagt er sich "lokaler Auftrag, nur Filerechte beachten und basedir und safe_mode". Kommt der Auftrag aber von "außen" über HTTP, dann sagt er sich, "oh, will ich dich Auftrag überhaupt annehmen? Erstmal die ganzen Filterbedingungen anschauen, die  man mir aufgetragen hat. Und wenn ich dann nach innen in mein Filesystem gucke, werde ich auch noch die zusätzlichen Bedingungen in .htaccess und httpd.conf für das Verzeichnis und die Files usw. beachten"

So (ähnlich) macht das jedenfalls der Apache. Der IIS macht, was er will...

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Wir setzen einfach mal voraus:
Ein Webserver hat immer nur direkten Zugriff auf das lokale Filesystem seiner Maschine. Kommt die Aufforderung an ihn nun von "innen", dann sagt er sich "lokaler Auftrag, nur Filerechte beachten und basedir und safe_mode". Kommt der Auftrag aber von "außen" über HTTP, dann sagt er sich, "oh, will ich dich Auftrag überhaupt annehmen? Erstmal die ganzen Filterbedingungen anschauen, die  man mir aufgetragen hat. Und wenn ich dann nach innen in mein Filesystem gucke, werde ich auch noch die zusätzlichen Bedingungen in .htaccess und httpd.conf für das Verzeichnis und die Files usw. beachten"

So (ähnlich) macht das jedenfalls der Apache. Der IIS macht, was er will...

Falsch. Ein Webserver ist per Definition eine Software, welche für die Auslieferung von Dateiinhalten per HTTP zuständig ist.

Dabei ist es vollkommen egal, ob der Zugriff von "innen" (IP 127.0.0.1 oder eine von lokalen Netzwerkdevices) kommt, oder von irgendwo aus dem Internet: Solange die Anforderung per HTTP erfolgt, gelten immer und gleichmäßig die definierten Zugriffsbeschränkungen (und sonstigen Konfigurationen). Ein "deny from all" sperrt den Zugriff auch für den auf derselben Maschine eingesetzten Browser. Und das ist auch gut so, denn alles andere wäre eine Sicherheitslücke.

Es ist eine vollkommen andere Sache, wenn ein vom Webserver ausgeführtes Skript seinerseits einen Dateizugriff auf das Dateisystem macht (zu beachten ist, dass die Datei dabei letztendlich gar nicht auf der eingebauten Festplatte liegen muß, weil "lokales Dateisystem" auch eingebundene externe Dateiserver sein können, die per NFS, SMB o.ä. Ressourcen zur Verfügung stellen). Hierbei gelten ausschließlich die definierten Zugriffsrechte der Dateien und Verzeichnisse, aber keinesfalls die Beschränkung von HTTP.

Dein Hinweis, dass der IIS macht, was er will, ist obendrein wenig hilfreich - reine Polemik, mehr nicht. Von Sicherheitslücken, die eventuell ausgenutzt werden, haben wir ja nicht gesprochen.

- Sven Rautenberg