Direkten Aufruf von Dateien verhindern

Status
Nicht offen für weitere Antworten.

nchristoph

Erfahrenes Mitglied
Hallo zusammen,

ich bin gerade dabei, meine Seite weiter abzusichern.

Ich habe schon Google und die Forensuche gequält und habe einige Wege gefunden, um den direkten Aufruf von Dateien zu verhindern.

Gefunden habe ich htaccess Einträge, PHP Codes mit define("blabla", true) usw.

Meine Frage an euch: welches ist der sicherste. Gibt es überhaupt einen, der sicherer ist als andere?

Wie sichert Ihr eure Seiten ab, um den direkten Aufruf zu verhindern?

grüsse
 
htaccess dürfte das sicherste sein. Denn das wird bereits vom Webserver gehandelt, da ist PHP gar nicht involviert.

Die kannst natürlich eine Basic-Auth mittels Headern in PHP machen. Das kommt auf das gleiche raus.
 
Direkter Aufruf:

http://deineseite.de/core/includes/irgendwas.includes.php

Kann, sofern z.b. Datenbank abfragen drinnen sind zum unschönen Ergebnis führen, dass man den pfad vom www_root weg bis zur Datei hin angezeigt kriegt also

www/user/public_html/code/includes/irgendwas.include.php

Das ist ein Sicherheitsrisiko.

@Saftmeister

Würde Basic-Auth nicht aber auch das Includen der Datei verhindern?

Wegen htaccess:

Ich habe überall nur gefunden, das Deny from all genügt. Ich habe das auch schon versucht allerdings hatte ich das Problem, dass z.b. aus dem Template Ordner nichts mehr eingebunden wurde.
 
Deshalb unterscheidet man in größeren Applikationen auch zwischen einem public-Ordner (Da sind HTML, JS, CSS, Bilder, usw drin), in dem alles steht, was der User sehen darf, und einem anderen Ordner (app, core, private), der geschützt ist und der User nicht sehen darf. Das einzige was der User an PHP-Dateien bei mir aufrufen kann ist eine index.php, diese leitet dann entsprechend weiter. (Stichwort FrontController)
 
Würde Basic-Auth nicht aber auch das Includen der Datei verhindern?

Nein, wie geschrieben: htaccess wird durch den Webserver erledigt. Da ist php nicht involviert. include() funktioniert im Dateisystem, da ist der Webserver-Dienst nicht involviert.

Ich hab das mal ein bisschen veranschaulicht.

1. Der Browser baut bspw. über Port 80 eine Verbindung mit dem Webserver auf und fordert die Datei index.php im DocumentRoot an.
2. Der Webserver kramt in seinem Dateisytem unter dem DocumentRoot nach der Datei, die in der URL angeben ist. Findet er die Datei nicht, liefert er einen 404-Fehler an den Browser ggf. mit etwas HTML für genauere Anzeige, was schief gelaufen ist.
3. Er schaut, ob in dem Ordner, in dem die Datei liegt, eine .htaccess-Datei vorhanden ist, wenn ja, wird diese verarbeitet. Ist dort eine Basic-Auth-Direktive hinterlegt, wird er den Browser zurückfragen und um Credentials (Benutzername + Passwort, Zertifikat, was-auch-immer) bitten. Der Browser muss sich also authentifizieren. Ggf. kommt noch eine Authorisierung zum Tragen, wenn auf bestimmte Resourcen bestimmte Authentifizierungen notwendig sind. Aber das ist erstmal egal und nicht Gegenstand deiner Frage.

Bis hier ist alles noch HTTP.

4. Der Webserver schaut nach erfolgreicher Authentifizierung nach, ob er für die Dateiendung einen speziellen Mimetypen festgelegt hat (AddType-Direktive), in dem Falle stellt er fest, das es sich um ein Dokument vom Typen application/x-httpd-php handelt und er diese Datei speziell behandeln soll. Also schickt er den Request an das PHP-Modul oder auch an die FCGI-Variante, je nach Konfiguration. Dabei werden die HTTP-Client-Header mit an das Modul übergeben. Dazu gehören Cookie/Session/File/POST- oder GET-Werte.

5. PHP verarbeitet das Script unter Berücksichtigung der Client-Header (oder auch nicht) ab. Das Ergebnis ist in der Regel ein Datenstrom, der vom Typ text/html ist und die Ausgabe des PHP-Scripts darstellt. Das Ergebnis hat außerdem eine bestimmte Größe (siehe strlen()). Die Ausgabe wird an den Webserver zurück gegeben, der sie an den Client zurück sendet. In den Scripts selbst kann dann ein oder mehrere include() stattfinden, die im Dateisystem behandelt werden. Anhand des Schaubildes kannst du erkennen, das der Webserver nicht involviert ist.

Fragen?
 

Anhänge

  • Browser+htaccess+php.png
    Browser+htaccess+php.png
    14,4 KB · Aufrufe: 43
Sorry für Doppel-Post, aber es gehört inhaltlich nicht zum vorigen Post.

alxy meinte sowas:

Code:
DocumentRoot
    |
    |----- [d] application
    |       |
    |       |----- [d] config
    |       |       |
    |       |       |----- config.php
    |       |
    |       |----- [d] modules
    |       |       |
    |       |       |----- [d] artikel
    |       |       |----- [d] news
    |       |       |----- .....
    |       |
    |       |----- .htaccess (Deny from all)
    |
    |----- [d] css
    |
    |----- [d] images
    |
    |----- index.php
    |----- .htaccess

Man erstellt unter DocumentRoot erstmal mehrere Ordner, in denen man gruppiert nach Zugehörigkeit der Dateien wiederum verschiedene Unterordner erzeugt. Es gibt einen geschützten Ordner, in dem über HTTP (siehe letzten Post) niemand zugreifen darf, der alle applikationsspezifischen Scripte enthält.
Dann noch ein paar für Bilder und Stylesheets, die ja über http erreichbar sein müssen, sonst kann der Browser sie ja nicht abrufen und anzeigen/verarbeiten.
Dann noch eine index.php, um die Zugriffe zu verarbeiten.
Letztendlich noch eine htaccess, um alle Zugriffe, die kein Bild oder CSS sind, an die index.php weiter zu leiten.

In der index.php wird dann fleißig include()'d und so die verschiedenen Anfragen an Module unterhalb der Applikation weitergeleitet. Die index.php entspricht dann dem erwähnten Front-Controller oder leitet die Anfragen an einen solchen speziellen um, der dann auf Module weiterleitet.

Applikationen von heute, die sich etwas professioneller schimpfen wollen, sollten ein solches Format verwenden. Die verschiedenen Frameworks arbeiten zu mindest nach diesem Schema.
 
Ok dass leuchtet mir ein, Dank für die SEHR ausführliche Erklärung Saftmeister.

Danke auch an alle anderen.

Eine Frage noch: gibt es besondere chmod Einstellungen die man für .htaccess beachten sollte?
 
Status
Nicht offen für weitere Antworten.
Zurück