Empêcher l'accès direct à un fichier d'inclusion PHP

J'ai un fichier php que j'utiliserai aussi exclusivement en tant qu'inclusion. Par conséquent, je voudrais lancer une erreur au lieu de l'exécuter lorsqu'elle est accessible directement en tapant l'URL au lieu d'être incluse.

Fondamentalement, je dois faire une vérification comme suit dans le fichier php:

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

Y a-t-il un moyen facile de faire ceci?

Le moyen le plus simple pour la situation générique «application PHP exécutée sur un serveur Apache que vous pouvez ou non contrôler complètement» est de placer vos inclusions dans un répertoire et de refuser l'accès à ce répertoire dans votre fichier .htaccess. Si vous utilisez Apache, placez-le dans un fichier appelé ".htaccess" dans le répertoire auquel vous ne voulez pas accéder:

Deny from all

Si vous avez réellement le contrôle total du serveur (plus courant de nos jours, même pour les petites applications que lorsque j'ai écrit cette réponse pour la première fois), la meilleure approche consiste à coller les fichiers que vous souhaitez protéger en dehors du répertoire à partir duquel votre serveur Web sert. . Donc, si votre application est dans /srv/YourApp/, définissez le serveur à partir duquel les fichiers sont diffusés /srv/YourApp/app/et insérez les inclusions /srv/YourApp/includes, de sorte qu'aucune URL ne puisse y accéder.

Ajoutez ceci à la page que vous souhaitez uniquement inclure

<?php
if(!defined('MyConst')) {
   die('Direct access not permitted');
}
?>

puis sur les pages qui l'incluent, ajoutez

<?php
define('MyConst', TRUE);
?>

J'ai un fichier dont j'ai besoin pour agir différemment lorsqu'il est inclus et lorsqu'il est accédé directement (principalement un print()vs return()) Voici un code modifié:

if(count(get_included_files()) ==1) exit("Direct access not permitted.");

Le fichier en cours d'accès est toujours un fichier inclus, d'où le == 1.  

La meilleure façon d'empêcher l'accès direct aux fichiers est de les placer en dehors de la racine du document du serveur Web (généralement, un niveau au-dessus). Vous pouvez toujours les inclure, mais il n'y a aucune possibilité que quelqu'un y accède via une requête http.

Je vais généralement jusqu'au bout et je place tous mes fichiers PHP en dehors de la racine du document à part le fichier d'amorçage - un index.php isolé dans la racine du document qui commence à acheminer l'ensemble du site Web / de l'application.

1: Vérification du nombre de fichiers inclus

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

Logique: PHP se ferme si le nombre minimum d'inclusions n'est pas atteint. Notez qu'avant PHP5, la page de base n'est pas considérée comme une inclusion.

2: Définition et vérification d'une constante globale

// 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');

Logique: Si la constante n'est pas définie, alors l'exécution n'a pas commencé à partir de la page de base et PHP arrêterait de s'exécuter.

Notez que pour des raisons de portabilité à travers les mises à niveau et les modifications futures, rendre cette méthode d'authentification modulaire réduirait considérablement la surcharge de codage car les modifications n'auront pas besoin d'être codées en dur dans chaque fichier.

// 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');

De cette façon, du code supplémentaire peut être ajouté à des checkdefined.php fins de journalisation et d'analyse, ainsi que pour générer des réponses appropriées.

Le crédit là où le crédit est dû: l' idée géniale de la portabilité est venue de cette réponse .

3: autorisation d'adresse à distance

// 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');

L'inconvénient de cette méthode est une exécution isolée, sauf si un jeton de session est fourni avec la requête interne. Vérifiez via l'adresse de bouclage dans le cas d'une configuration de serveur unique, ou une liste blanche d'adresses pour une infrastructure de serveur multi-serveur ou à charge équilibrée.

4: autorisation de jeton

Similaire à la méthode précédente, on peut utiliser GET ou POST pour passer un jeton d'autorisation au fichier d'inclusion:

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

Une méthode très compliquée, mais peut-être aussi la plus sûre et la plus polyvalente à la fois, lorsqu'elle est utilisée de la bonne manière.

5: configuration spécifique au serveur Web

La plupart des serveurs vous permettent d'attribuer des autorisations pour des fichiers ou des répertoires individuels. Vous pouvez placer toutes vos inclusions dans de tels répertoires restreints et configurer le serveur pour les refuser.

Par exemple dans APACHE, la configuration est stockée dans le .htaccessfichier. Tutoriel ici .

Notez cependant que les configurations spécifiques au serveur ne sont pas recommandées par moi car elles sont mauvaises pour la portabilité entre différents serveurs Web. Dans des cas comme les systèmes de gestion de contenu où l'algorithme de refus est complexe ou la liste des répertoires refusés est assez volumineuse, cela ne peut que rendre les sessions de reconfiguration plutôt horribles. En fin de compte, il est préférable de gérer cela dans le code.

6: Placement inclut dans un répertoire sécurisé EN DEHORS de la racine du site

Moins préféré en raison des limitations d'accès dans les environnements de serveur, mais une méthode plutôt puissante si vous avez accès au système de fichiers.

//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");

Logique:

• L'utilisateur ne peut demander aucun fichier en dehors du htdocsdossier car les liens seraient en dehors du champ d'application du système d'adresse du site Web.
• Le serveur php accède nativement au système de fichiers, et peut donc accéder aux fichiers sur un ordinateur, tout comme le peut un programme normal avec les privilèges requis.
• En plaçant les fichiers d'inclusion dans ce répertoire, vous pouvez vous assurer que le serveur php peut y accéder, tandis que le hotlinking est refusé à l'utilisateur.
• Même si la configuration d'accès au système de fichiers du serveur Web n'était pas effectuée correctement, cette méthode empêcherait ces fichiers de devenir publics accidentellement.

Veuillez excuser mes conventions de codage peu orthodoxes. Tout commentaire est apprécié.

Une alternative (ou un complément) à la solution de Chuck serait de refuser l'accès aux fichiers correspondant à un modèle spécifique en mettant quelque chose comme ça dans votre fichier .htaccess

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

En fait, mon conseil est de faire toutes ces meilleures pratiques.

• Placez les documents en dehors de la racine Web OU dans un répertoire auquel l'accès est refusé par le serveur Web ET
• Utilisez une définition dans vos documents visibles que les documents masqués vérifient:

      if (!defined(INCL_FILE_FOO)) {
          header('HTTP/1.0 403 Forbidden');
          exit;
      }

De cette façon, si les fichiers sont égarés d'une manière ou d'une autre (une opération ftp erronée), ils sont toujours protégés.

J'ai eu ce problème une fois, résolu avec:

if (strpos($_SERVER['REQUEST_URI'], basename(__FILE__)) !== false) ...

mais la solution idéale est de placer le fichier en dehors de la racine du document du serveur Web, comme mentionné dans une autre réponse.

Vous feriez mieux de créer une application avec un point d'entrée, c'est-à-dire que tous les fichiers doivent être atteints à partir de index.php

Placez ceci dans index.php

define(A,true);

Cette vérification doit s'exécuter dans chaque fichier lié (via require ou include)

defined('A') or die(header('HTTP/1.0 403 Forbidden'));

Je voulais restreindre l'accès au fichier PHP directement, mais aussi pouvoir l'appeler via jQuery $.ajax (XMLHttpRequest). Voici ce qui a fonctionné pour moi.

if (empty($_SERVER["HTTP_X_REQUESTED_WITH"]) && $_SERVER["HTTP_X_REQUESTED_WITH"] != "XMLHttpRequest") {
    if (realpath($_SERVER["SCRIPT_FILENAME"]) == __FILE__) { // direct access denied
        header("Location: /403");
        exit;
    }
}

Le moyen le plus simple est de définir une variable dans le fichier qui appelle include, telle que

$including = true;

Ensuite, dans le fichier qui est inclus, vérifiez la variable

if (!$including) exit("direct access not permitted");

Outre la manière .htaccess, j'ai vu un motif utile dans divers frameworks, par exemple en ruby ​​on rails. Ils ont un répertoire pub / séparé dans le répertoire racine de l'application et les répertoires de la bibliothèque vivent dans des répertoires au même niveau que pub /. Quelque chose comme ça (pas idéal, mais vous voyez l'idée):

app/
 |
 +--pub/
 |
 +--lib/
 |
 +--conf/
 |
 +--models/
 |
 +--views/
 |
 +--controllers/

Vous configurez votre serveur Web pour utiliser pub / comme racine de document. Cela offre une meilleure protection à vos scripts: alors qu'ils peuvent accéder à partir de la racine du document pour charger les composants nécessaires, il est impossible d'accéder aux composants depuis Internet. Un autre avantage en plus de la sécurité est que tout est au même endroit.

Cette configuration est meilleure que la simple création de vérifications dans chaque fichier inclus, car le message "accès non autorisé" est un indice pour les attaquants, et il est meilleur que la configuration .htaccess car il n'est pas basé sur une liste blanche: si vous bousillez les extensions de fichier il ne sera pas visible dans les répertoires lib /, conf / etc.

Qu'est-ce que Joomla! fait est de définir une constante dans un fichier racine et de vérifier si elle est définie dans les fichiers inclus.

defined('_JEXEC') or die('Restricted access');

ou sinon

on peut garder tous les fichiers hors de portée d'une requête http en les plaçant en dehors du répertoire webroot comme le recommandent la plupart des frameworks comme CodeIgniter.

ou même en plaçant un fichier .htaccess dans le dossier d'inclusion et en écrivant des règles, vous pouvez empêcher l'accès direct.

debug_backtrace() || die ("Direct access not permitted");

Ma réponse est quelque peu différente dans son approche, mais comprend bon nombre des réponses fournies ici. Je recommanderais une approche à plusieurs volets:

1. .htaccess et restrictions Apache à coup sûr
2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

TOUTEFOIS, l' defined or dieapproche présente un certain nombre d'échecs. Tout d'abord, c'est une vraie douleur dans les hypothèses à tester et déboguer. Deuxièmement, cela implique une refactorisation terriblement et ennuyeuse si vous changez d'avis. "Trouver et remplacer!" vous dites. Oui, mais êtes-vous sûr que c'est écrit exactement de la même façon partout, hmmm? Maintenant, multipliez cela avec des milliers de fichiers ... oO

Et puis il y a .htaccess. Que se passe-t-il si votre code est distribué sur des sites où l'administrateur n'est pas si scrupuleux? Si vous ne comptez que sur .htaccess pour sécuriser vos fichiers, vous aurez également besoin a) d'une sauvegarde, b) d'une boîte de mouchoirs pour sécher vos larmes, c) d'un extincteur pour éteindre les flammes dans tous les courriers électroniques des personnes en utilisant votre code.

Je sais donc que la question demande le "plus simple", mais je pense que ce que cela demande, c'est plus de "codage défensif".

Ce que je suggère est:

1. Avant l'un de vos scripts require('ifyoulieyougonnadie.php');( pas include() et en remplacement de defined or die)

2. Dans ifyoulieyougonnadie.php, faites des choses logiques - vérifiez les différentes constantes, appelez le script, testez l'hôte local et autres - puis implémentez votre die(), throw new Exception, 403, etc.

   Je crée mon propre framework avec deux points d'entrée possibles - le principal index.php (framework Joomla) et ajaxrouter.php (mon framework) - donc en fonction du point d'entrée, je vérifie des choses différentes. Si la demande ifyoulieyougonnadie.phpne provient pas de l'un de ces deux fichiers, je sais que des manigances sont en cours!

   Mais que faire si j'ajoute un nouveau point d'entrée? Pas de soucis. Je change juste ifyoulieyougonnadie.phpet je suis trié, plus pas de «recherche et remplacement». Hourra!

   Et si je décidais de déplacer certains de mes scripts pour faire un framework différent qui n'a pas les mêmes constantes defined()? ... Hourra! ^ _ ^

J'ai trouvé que cette stratégie rend le développement beaucoup plus amusant et beaucoup moins:

/**
 * Hmmm... why is my netbeans debugger only showing a blank white page 
 * for this script (that is being tested outside the framework)?
 * Later... I just don't understand why my code is not working...
 * Much later... There are no error messages or anything! 
 * Why is it not working!?!
 * I HATE PHP!!!
 * 
 * Scroll back to the top of my 100s of lines of code...
 * U_U
 *
 * Sorry PHP. I didn't mean what I said. I was just upset.
 */

 // defined('_JEXEC') or die();

 class perfectlyWorkingCode {}

 perfectlyWorkingCode::nowDoingStuffBecauseIRememberedToCommentOutTheDie();

Si plus précisément, vous devez utiliser cette condition:

if (array_search(__FILE__, get_included_files()) === 0) {
    echo 'direct access';
}
else {
    echo 'included';
}

get_included_files () retourne un tableau indexé contenant les noms de tous les fichiers inclus (si le fichier est exécuté, il a été inclus et son nom est dans le tableau). Ainsi, lorsque le fichier est directement accédé, son nom est le premier du tableau, tous les autres fichiers du tableau ont été inclus.

<?php
if (eregi("YOUR_INCLUDED_PHP_FILE_NAME", $_SERVER['PHP_SELF'])) { 
 die("<h4>You don't have right permission to access this file directly.</h4>");
}
?>

placez le code ci-dessus en haut de votre fichier php inclus.

ex:

<?php
if (eregi("some_functions.php", $_SERVER['PHP_SELF'])) {
    die("<h4>You don't have right permission to access this file directly.</h4>");
}

    // do something
?>

Le code suivant est utilisé dans le CMS Flatnux ( http://flatnux.altervista.org ):

if ( strpos(strtolower($_SERVER['SCRIPT_NAME']),strtolower(basename(__FILE__))) )
{
    header("Location: ../../index.php");
    die("...");
}

J'ai trouvé cette solution uniquement php et invariable qui fonctionne à la fois avec http et cli:

Définissez une fonction:

function forbidDirectAccess($file) {
    $self = getcwd()."/".trim($_SERVER["PHP_SELF"], "/");
    (substr_compare($file, $self, -strlen($self)) != 0) or die('Restricted access');
}

Appelez la fonction du fichier à laquelle vous souhaitez empêcher l'accès direct:

forbidDirectAccess(__FILE__);

La plupart des solutions données ci-dessus à cette question ne fonctionnent pas en mode Cli.

if (basename($_SERVER['PHP_SELF']) == basename(__FILE__)) { die('Access denied'); };

<?php       
$url = 'http://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'];
  if (false !== strpos($url,'.php')) {
      die ("Direct access not premitted");
  }
?>

Le stockage de vos fichiers d'inclusion en dehors du répertoire accessible sur le Web a été mentionné à plusieurs reprises et constitue certainement une bonne stratégie lorsque cela est possible. Cependant, une autre option que je n'ai pas encore vue mentionnée: assurez-vous que vos fichiers d'inclusion ne contiennent aucun code exécutable . Si vos fichiers d'inclusion définissent simplement des fonctions et des classes, et n'ont pas de code autre que cela, ils produiront simplement une page vierge lorsqu'ils seront accédés directement.

Autorisez par tous les moyens un accès direct à ce fichier depuis le navigateur: cela ne fera rien . Il définit certaines fonctions, mais aucune d'elles n'est appelée, donc aucune d'elles ne s'exécute.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

La même chose s'applique aux fichiers qui ne contiennent que des classes PHP, et rien d'autre.

C'est toujours une bonne idée de conserver vos fichiers en dehors du répertoire Web lorsque cela est possible.

• Vous pouvez accidentellement désactiver PHP, auquel cas votre serveur peut envoyer le contenu des fichiers PHP au navigateur, au lieu d'exécuter PHP et d'envoyer le résultat. Cela pourrait entraîner une fuite de votre code (y compris les mots de passe de base de données, les clés API, etc.).
• Les fichiers du répertoire Web squattent les URL que vous souhaitez peut-être utiliser pour votre application. Je travaille avec un CMS qui ne peut pas avoir une page appelée system, car cela entrerait en conflit avec un chemin utilisé pour le code. Je trouve cela ennuyeux.

Faites quelque chose comme:

<?php
if ($_SERVER['SCRIPT_FILENAME'] == '<path to php include file>') {
    header('HTTP/1.0 403 Forbidden');
    exit('Forbidden');
}
?>

Vous pouvez utiliser la méthode suivante ci-dessous bien qu'elle présente un défaut, car elle peut être truquée, sauf si vous pouvez ajouter une autre ligne de code pour vous assurer que la requête provient uniquement de votre serveur soit en utilisant Javascript. Vous pouvez placer ce code dans la section Corps de votre code HTML pour que l'erreur s'affiche.

<?
if(!isset($_SERVER['HTTP_REQUEST'])) { include ('error_file.php'); }
else { ?>

Placez votre autre code HTML ici

<? } ?>

Terminez-le comme ceci, de sorte que la sortie de l'erreur s'affichera toujours dans la section body, si c'est comme ça que vous voulez qu'elle soit.

Je suggère de ne pas utiliser $_SERVERpour des raisons de sécurité.
Vous pouvez utiliser une variable comme $root=true;dans le premier fichier qui en comprenait un autre.
et utiliser isset($root)au début du deuxième fichier à inclure.

Ce que vous pouvez également faire, c'est protéger le répertoire par mot de passe et y conserver tous vos scripts php, bien sûr à l'exception du fichier index.php, car au moment de l'inclusion, le mot de passe ne sera pas requis car il ne sera requis que pour l'accès http. ce qu'il fera est également de vous fournir la possibilité d'accéder à vos scripts au cas où vous le voudriez car vous aurez un mot de passe pour accéder à ce répertoire. vous devrez configurer le fichier .htaccess pour le répertoire et un fichier .htpasswd pour authentifier l'utilisateur.

eh bien, vous pouvez également utiliser l'une des solutions fournies ci-dessus au cas où vous estimeriez ne pas avoir besoin d'accéder à ces fichiers normalement car vous pouvez toujours y accéder via cPanel, etc.

J'espère que cela t'aides

Le moyen le plus simple est de stocker vos inclusions en dehors du répertoire Web. De cette façon, le serveur y a accès mais pas de machine extérieure. Le seul inconvénient est que vous devez pouvoir accéder à cette partie de votre serveur. L'avantage est qu'il ne nécessite aucune installation, configuration ou stress supplémentaire sur le code / serveur.

Je n'ai pas trouvé les suggestions avec .htaccess si bonnes car elles peuvent bloquer d'autres contenus de ce dossier auxquels vous voudrez peut-être autoriser l'utilisateur à accéder, voici ma solution:

$currentFileInfo = pathinfo(__FILE__);
$requestInfo = pathinfo($_SERVER['REQUEST_URI']);
if($currentFileInfo['basename'] == $requestInfo['basename']){
    // direct access to file
}

if ( ! defined('BASEPATH')) exit('No direct script access allowed');

fera le travail en douceur

Solution mentionnée précédemment avec vérification de la version PHP ajoutée:

    $max_includes = version_compare(PHP_VERSION, '5', '<') ? 0 : 1;
    if (count(get_included_files()) <= $max_includes)
    {
        exit('Direct access is not allowed.');
    }