Direkten Zugriff auf eine PHP-Include-Datei verhindern

Ich habe eine PHP-Datei, die ich ausschließlich als Include verwenden werde. Daher möchte ich einen Fehler werfen, anstatt ihn auszuführen, wenn direkt darauf zugegriffen wird, indem die URL eingegeben wird, anstatt eingeschlossen zu werden.

Grundsätzlich muss ich in der PHP-Datei eine Überprüfung wie folgt durchführen:

if ( $REQUEST_URL == $URL_OF_CURRENT_PAGE ) die ("Direct access not premitted");

Gibt es eine einfache Möglichkeit, dies zu tun?

Der einfachste Weg für die generische Situation „PHP-App, die auf einem Apache-Server ausgeführt wird, den Sie vollständig kontrollieren können oder nicht“ ist, Ihre Includes in einem Verzeichnis abzulegen und den Zugriff auf dieses Verzeichnis in Ihrer .htaccess-Datei zu verweigern. Um den Leuten das Googeln zu ersparen, wenn Sie Apache verwenden, fügen Sie dies in eine Datei namens “.htaccess” in das Verzeichnis ein, auf das Sie nicht zugreifen möchten:

Deny from all

Wenn Sie tatsächlich die volle Kontrolle über den Server haben (heutzutage häufiger sogar für kleine Apps als zu dem Zeitpunkt, als ich diese Antwort zum ersten Mal schrieb), besteht der beste Ansatz darin, die Dateien, die Sie schützen möchten, außerhalb des Verzeichnisses zu platzieren, aus dem Ihr Webserver dient . Also, wenn Ihre App drin ist /srv/YourApp/legen Sie den Server fest, von dem Dateien bereitgestellt werden /srv/YourApp/app/ und fügt die Includes ein /srv/YourApp/includesalso gibt es buchstäblich keine URL, die auf sie zugreifen kann.

1: Überprüfen der Anzahl der enthaltenen Dateien

if( count(get_included_files()) == ((version_compare(PHP_VERSION, '5.0.0', '>='))?1:0) )
{
    exit('Restricted Access');
}

Logik: PHP wird beendet, wenn die minimale Include-Anzahl nicht erreicht wird. Beachten Sie, dass vor PHP5 die Basisseite nicht als Include betrachtet wird.

2: Definieren und Verifizieren einer globalen Konstante

// In the base page (directly accessed):
define('_DEFVAR', 1);

// In the include files (where direct access isn't permitted):
defined('_DEFVAR') or exit('Restricted Access');

Logik: Wenn die Konstante nicht definiert ist, startete die Ausführung nicht von der Basisseite und PHP würde die Ausführung stoppen.

Notiz dass aus Gründen der Übertragbarkeit über Upgrades und zukünftige Änderungen eine Modularisierung dieser Authentifizierungsmethode den Codierungsaufwand erheblich reduzieren würde, da die Änderungen nicht für jede einzelne Datei fest codiert werden müssen.

// Put the code in a separate file instead, say 'checkdefined.php':
defined('_DEFVAR') or exit('Restricted Access');

// Replace the same code in the include files with:
require_once('checkdefined.php');

Auf diese Weise kann zusätzlicher Code hinzugefügt werden checkdefined.php für Protokollierungs- und Analysezwecke sowie zur Generierung angemessener Antworten.

Kredit wem Kredit gebührt: Aus dieser Antwort entstand die brillante Idee der Portabilität. Diese Methode hat jedoch einen Nachteil. Dateien in verschiedenen Ordnern erfordern möglicherweise unterschiedliche Adressen, um diese Datei zu adressieren. Und die Server-Root-basierte Adressierung funktioniert möglicherweise nicht, wenn Sie die aktuelle Website von einem Unterordner der Hauptseite aus ausführen.

3: Remote-Adressautorisierung

// Call the include from the base page(directly accessed):
$includeData = file_get_contents("http://127.0.0.1/component.php?auth=token");

// In the include files (where direct access isn't permitted):
$src = $_SERVER['REMOTE_ADDR']; // Get the source address
$auth = authoriseIP($src); // Authorisation algorithm
if( !$auth ) exit('Restricted Access');

Der Nachteil bei dieser Methode ist die isolierte Ausführung, es sei denn, ein Sitzungstoken wird mit der internen Anforderung bereitgestellt. Überprüfen Sie dies über die Loopback-Adresse im Falle einer Einzelserverkonfiguration oder über eine Adress-Whitelist für eine Serverinfrastruktur mit mehreren Servern oder mit Lastenausgleich.

4: Token-Autorisierung

Ähnlich wie bei der vorherigen Methode kann man GET oder POST verwenden, um ein Autorisierungstoken an die Include-Datei zu übergeben:

if($key!="serv97602"){header("Location: ".$dart);exit();}

Eine sehr umständliche Methode, aber bei richtiger Anwendung vielleicht auch die sicherste und vielseitigste zugleich.

5: Webserverspezifische Konfiguration

Bei den meisten Servern können Sie Berechtigungen für einzelne Dateien oder Verzeichnisse zuweisen. Sie könnten alle Ihre Includes in solchen eingeschränkten Verzeichnissen platzieren und den Server so konfigurieren, dass er sie ablehnt.

Beispielsweise wird in Apache die Konfiguration in der gespeichert .htaccess Datei. Lernprogramm Hier.

Notiz Allerdings werden serverspezifische Konfigurationen von mir nicht empfohlen, da sie schlecht für die Portabilität zwischen verschiedenen Webservern sind. In Fällen wie Content-Management-Systemen, bei denen der Deny-Algorithmus komplex ist oder die Liste der abgelehnten Verzeichnisse ziemlich groß ist, kann dies die Rekonfigurationssitzungen nur ziemlich grausam machen. Am Ende ist es am besten, dies im Code zu behandeln.

6: Platzieren von Includes in einem sicheren Verzeichnis AUSSERHALB des Site-Stammverzeichnisses

Aufgrund von Zugriffsbeschränkungen in Serverumgebungen am wenigsten bevorzugt, aber eine ziemlich leistungsfähige Methode, wenn Sie Zugriff auf das Dateisystem haben.

//Your secure dir path based on server file-system
$secure_dir=dirname($_SERVER['DOCUMENT_ROOT']).DIRECTORY_SEPARATOR."secure".DIRECTORY_SEPARATOR;
include($secure_dir."securepage.php");

Logik:

• Der Benutzer kann keine Datei außerhalb von anfordern htdocs Ordner, da die Links außerhalb des Bereichs des Adresssystems der Website liegen würden.
• Der PHP-Server greift nativ auf das Dateisystem zu und kann daher auf Dateien auf einem Computer zugreifen, genau wie ein normales Programm mit den erforderlichen Berechtigungen.
• Indem Sie die Include-Dateien in dieses Verzeichnis legen, können Sie sicherstellen, dass der PHP-Server darauf zugreifen kann, während dem Benutzer das Hotlinking verweigert wird.
• Selbst wenn die Konfiguration des Dateisystemzugriffs des Webservers nicht ordnungsgemäß durchgeführt wurde, würde diese Methode verhindern, dass diese Dateien versehentlich veröffentlicht werden.

Bitte entschuldigen Sie meine unorthodoxen Programmierkonventionen. Jedes Feedback ist willkommen.

Der beste Weg, den direkten Zugriff auf Dateien zu verhindern, besteht darin, sie außerhalb des Dokumentstammverzeichnisses des Webservers zu platzieren (normalerweise eine Ebene darüber). Sie können sie immer noch einschließen, aber es gibt keine Möglichkeit, dass jemand über eine http-Anforderung darauf zugreift.

Normalerweise gehe ich den ganzen Weg und platziere alle meine PHP-Dateien außerhalb des Dokumentstammverzeichnisses, abgesehen von der Bootstrap-Datei – eine einsame index.php im Document Root, die mit dem Routing der gesamten Website/Anwendung beginnt.

Eine Alternative (oder Ergänzung) zu Chucks Lösung wäre, den Zugriff auf Dateien zu verweigern, die einem bestimmten Muster entsprechen, indem Sie so etwas in Ihre .htaccess-Datei einfügen

<FilesMatch "\.(inc)$">
    Order deny,allow
    Deny from all
</FilesMatch>