Éviter l'accès direct à php include de fichier

L'ajouter à la page que vous souhaitez seulement être inclus

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

alors sur les pages que l'inclure ajouter

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

La meilleure façon de prévenir l'accès direct aux fichiers est de les placer à l'extérieur de la web-serveur racine du document (généralement, un niveau au-dessus). Vous pouvez toujours inclure, mais il n'y a pas de possibilité de quelqu'un d'accéder par le biais d'une requête http.

J'ai l'habitude d'aller tout le chemin, et de placer l'ensemble de mes fichiers PHP en dehors de la racine du document en dehors de la fichier de bootstrap - un seul index.php dans la racine du document qui commence le routage de l'ensemble du site web/de l'application.

1: Vérifier le nombre de fichiers inclus

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

Logique: PHP quitte si le minimum inclure le comte n'est pas remplie. Noter que, avant PHP5, la page de base n'est pas considéré comme un include.

---

2: Définir et vérifier 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, l'exécution n'a pas commencé à partir de la page de base, et PHP allait s'arrêter.

---

3: Distance de l'adresse de l'autorisation

//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 isolé à l'exécution, à moins qu'une session-jeton fourni avec la demande interne. Vérifier par l'intermédiaire de la boucle de retour de l'adresse dans le cas d'un seul serveur configuration, ou une adresse de liste blanche pour un multi-serveur ou à charge équilibrée de l'infrastructure serveur.

---

4: Jeton d'autorisation

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

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

Une très salissant méthode, mais peut-être aussi le plus sûr et le plus polyvalent dans le même temps, lorsqu'il est utilisé dans le droit chemin.

---

5: Serveur de configuration spécifiques

La plupart des serveurs vous permettent d'attribuer des autorisations pour les fichiers ou les répertoires. Vous pourrez y mettre tous vos inclut dans les répertoires, et que le serveur soit configuré pour les refuser.

Par exemple dans APACHE, la configuration est stockée dans la .htaccess fichier. Tutoriel ici.

Note cependant que serveur de configurations spécifiques ne sont pas recommandés par moi parce qu'ils sont mauvais pour la portabilité sur différents serveurs web. Dans de tels cas, où le nier-l'algorithme est complexe ou la liste de refus d'annuaires est plutôt grand, il peut seulement faire la reconfiguration des sessions plutôt macabre. En fin de compte, il est préférable de gérer dans le code.

---

6: Placer les inclut dans un répertoire sécurisé à l'EXTÉRIEUR de la racine du site

Moins privilégiées en raison de restrictions d'accès dans les environnements de serveurs, mais plutôt une méthode 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 pas demander n'importe quel fichier en dehors de la htdocs dossier que les liens seront en dehors de la portée de l'adresse du site web du système.
• Le serveur php accède au système de fichiers natif, et peut donc accéder à des fichiers sur un ordinateur, exactement comme un programme normal avec les privilèges requis peut.
• En plaçant les fichiers dans ce répertoire, vous pouvez vous assurer que le serveur php arrive à y accéder, tandis que le hotlinking est refusé à l'utilisateur.
• Même si le serveur de système de fichiers de configuration d'accès n'a pas été fait correctement, cette méthode permettrait d'éviter ces fichiers de devenir public accidentellement.

---

S'il vous plaît excusez mon peu orthodoxe des conventions de codage. Tout commentaire est apprécié.

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

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

mais l'idéal est de placer le fichier à l'extérieur de la web-serveur racine du document, tel que mentionné dans une autre réponse.

La façon la plus simple est de mettre une variable dans le fichier qui comprennent des appels, comme

$including = true;

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

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

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

Outre le .htaccess passant, j'ai vu un pattern très utile dans différents cadres, par exemple en ruby on rails. Ils ont un pub/répertoire dans le répertoire racine de l'application et de la bibliothèque sont les répertoires qui vivent dans les annuaires de la même niveau comme pub/. Quelque chose comme ceci (pas l'idéal, mais vous voyez l'idée):

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

De configurer votre serveur web pour utiliser pub/comme racine du document. Cela offre une meilleure protection à vos scripts: alors qu'ils peuvent atteindre à partir de la racine du document à charger les composants nécessaires, il est impossible d'accéder aux composants de l'internet. Un autre avantage en plus de la sécurité, c'est que tout est dans un seul endroit.

Cette configuration est mieux que de créer des contrôles dans chaque fichier inclus parce que "accès non autorisé" message est un indice pour les attaquants, et c'est mieux qu' .htaccess configuration car il n'est pas blanc-liste: si vous bousiller les extensions de fichier, il ne sera pas visible dans la lib/conf/etc. les répertoires.

<?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 dans le haut de votre inclus fichier php.

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
?>

J'ai trouvé ce php-seulement et invariable solution qui fonctionne à la fois avec le protocole http et de la cli :

Définir une fonction :

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

Appel de la fonction dans le fichier que vous souhaitez éviter l'accès direct à :

forbidDirectAccess(__FILE__);

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

Ma réponse est un peu différent, mais dans l'approche inclut un grand nombre de réponses fournies ici. Je recommande une approche à volets multiples:

1. .htaccess et Apache restrictions pour assurer
2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

CEPENDANT la defined or die approche présente un certain nombre de manquements. Tout d'abord, c'est une vraie douleur dans les hypothèses à tester et déboguer avec. Deuxièmement, elle implique horriblement, l'état d'esprit numbingly ennuyeux refactoring si vous changez d'avis. "Rechercher et remplacer!" dites-vous. Oui, mais comment êtes-vous sûr qu'il est écrit exactement la même chose partout, hmmm? Maintenant, multipliez ce avec des milliers de fichiers... o.O

Et puis il y a des .htaccess. Qu'advient-il si votre code est distribué sur les sites où l'administrateur n'est pas si scrupuleux? Si vous comptez uniquement sur .htaccess pour sécuriser vos fichiers, vous allez aussi avoir besoin d'un) une copie de sauvegarde, b) une boîte de mouchoirs pour sécher vos larmes, c) un extincteur pour éteindre les flammes dans tous les hatemail de personnes à l'aide de votre code.

Donc je sais que la question demande le plus "facile", mais je pense que cela demande est plus sur la défensive "codage".

Ce que je suggère est:

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

2. Dans ifyoulieyougonnadie.php, faire un peu de logique trucs - vérifier les différentes constantes, l'appel de script, localhost test et de tel - puis de mettre en œuvre votre die(), throw new Exception, 403, etc.

   Je suis entrain de créer ma propre structure avec deux points d'entrée principale index.php (Joomla), et un cadre ajaxrouter.php (mon cadre) - donc en fonction du point d'entrée, je check pour des choses différentes. Si la demande de ifyoulieyougonnadie.php ne vient pas de l'un de ces deux fichiers, je sais manigances sont en train d'être réalisée!

   Mais ce que si j'ajoute un nouveau point d'entrée? Pas de soucis. Je viens de changer ifyoulieyougonnadie.php et je suis triés, plus aucun "rechercher et remplacer". Hourra!

   Ce que si j'ai décidé de passer certains de mes scripts pour faire un cadre différent qui n'a pas les mêmes constantes defined()? ... Hourra! ^_^

J'ai trouvé cette stratégie de développement beaucoup plus agréable 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();

Vous pouvez utiliser la méthode ci-dessous, bien que, il a un défaut, car il peut être faux, sauf si vous pouvez ajouter une autre ligne de code assurez-vous que la demande ne vient que de votre serveur à l'aide de Javascript.
Vous pouvez placer ce code dans la section de Corps de votre code HTML, donc l'erreur de shows.

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

Placez votre autre code HTML ici

<? } ?>

Fin comme cela, de sorte que la sortie de l'erreur sera toujours montrer dans la section de corps, si c'est la façon dont vous voulez qu'il soit.

Ce que vous pouvez également faire est de protéger le mot de passe du répertoire et de garder tous vos scripts php de là, bien sûr, à l'exception de la index.php fichier, comme à l'époque d'inclure le mot de passe n'est pas nécessaire, car il sera requis uniquement pour l'accès http. ce qu'il va faire est de vous offrons également la possibilité d'accéder à vos scripts dans le cas où vous voulez tant que vous aurez le mot de passe pour accéder à ce répertoire. vous aurez besoin pour l'installation .fichier htaccess du répertoire et une .un fichier htpasswd pour authentifier l'utilisateur.

bien, vous pouvez également utiliser l'une des solutions ci-dessus dans le cas où vous sentez que vous n'avez pas besoin d'accéder à ces fichiers, normalement, parce que vous pouvez toujours y accéder via cPanel etc.

Espère que cette aide

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

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

le travail se fera en douceur

c'est ce que google utilise dans leur php exemples voir ici

if (php_sapi_name() != 'cli') {
  throw new \Exception('This application must be run on the command line.');
}

Mentionné plus tôt, la solution avec la version de PHP vérifier ajouté:

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

Vous pouvez également essayer de renommer le document que vous ne voulez pas les gens à être en mesure d'accéder. Vous pouvez la renommer 47d8498d3w.php par exemple. Faites juste quelque chose que la plupart des gens ne sera probablement pas le type de comme http-request. Si vous incluez le fichier avec SSI ou PHP, l'utilisateur ne sera pas en mesure de voir le nom du document, de toute façon.