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


166

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?


10
au lieu de die (), vous devriez tester l'en-tête '("HTTP / 1.1 404 File Not Found", 404); sortie;'. Cela fera (du moins sur Apache) que le serveur renvoie la page 404 normale.
gnud le

Voici deux méthodes simples que j'ai expliquées pour désactiver l'accès direct dans les fichiers PHP inclus - codespeedy.com/disable-direct-access-to-the-php-include-file
Faruque Ahamed Mollick

Réponses:


174

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.


1
Merci, puisque j'ai un contrôle total sur le serveur sur lequel j'exécute cette application, c'est la réponse que j'ai choisie.
Alterlife

24
si vous avez le contrôle total du serveur, il est préférable de placer la configuration dans une directive de répertoire dans le fichier de configuration de l'hôte virtuel. Apache ne le lit qu'une seule fois au démarrage, .htaccess est lu à chaque accès et ralentit le serveur
Eineki

22
Ce serait bien d'avoir un exemple de fichier .htaccess dans le cadre de cette réponse.
Graham Lea

7
<Files ~ "\.inc$"> Order Allow,Deny Deny from All </Files>
Dracorat le

11
@James: De plus, tout le monde ne pense pas que Stack Overflow devrait être un site "plz send teh codez". S'il répond clairement à la question, alors c'est une bonne réponse. Fournir un exemple où aucun n'est nécessaire encourage uniquement le codage par copier-coller.
Chuck

188

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

3
J'ai vraiment besoin d'apprendre à taper plus rapidement. C'est la même manière que je suggérerais, car c'est plus sûr qu'une méthode qui utilise une variable pour vérifier. Comme avec certaines configurations PHP, il peut être possible de remplacer la variable.
Mark Davidson

3
C'est ainsi que quelques applications «grand public» le gèrent. Je sais que Joomla le fait de cette façon et je pense que Wiki, Wordpress et d'autres aussi.
UnkwnTech

1
Peut-être que le message est trop utile pour un hacker (aucun utilisateur réel ne trouverait ces pages), vous pouvez simplement envoyer un en-tête de redirection et arrêter le traitement php.
bandi le

7
Envoyez simplement un en-tête 404 et quittez - la page d'erreur sera identique aux pages 404 normales (au moins sur Apache).
gnud le

4
@ Smile.Hunter: il s'agit de bloquer l'accès à la visualisation directe de vos fichiers de script d'inclusion / bibliothèque, la réponse fonctionne. S'ils ont créé somefile.phpsur votre serveur et y ont ajouté votre définition, cela ne leur permet toujours pas d'accéder directement au fichier d'inclusion. Cela leur permettra "d'inclure" vos fichiers de bibliothèque, mais s'ils vont assez loin pour créer des fichiers sur votre serveur et connaître vos scripts de définition / inclusion, vous rencontrez d'autres problèmes qui empêchent probablement d'écrire leur propre fichier avec votre définition en premier lieu .
James

114

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.  


12
C'est en fait une sacrée idée, vérifier le nombre de fichiers inclus. Je me demande ce qui est le mieux: utiliser définit ou utiliser cette méthode? Cela semble plus autonome.
Akoi Meexx

C'est la première fois que je vois quelqu'un proposer ça. Je ne sais pas pourquoi, car cela semble aussi autonome que possible, et il mesure directement ce que vous voulez vraiment savoir (si est inclus ou non) plutôt que de mesurer quelque chose supposé être associé (comme une certaine constante ou une certains emplacements interdits par .htaccess). Belle.
Jimbo Jonny

Celui-ci est vraiment cool car utiliser .htaccess pour bloquer tous les fichiers .php peut ne pas être possible tout le temps car il peut y avoir des fichiers dans le même répertoire qui doivent être appelés directement ou même par javascripts. Merci pour cette bonne idée!
Anuj

3
Cela ne fonctionne qu'en PHP5 et plus. Pré-PHP5, vous voulez comparer à nouveau 0 au lieu de 1.
jmucchiello

C'est une solution vraiment intelligente et vous permet de contrôler l'accès direct, pas seulement de le bloquer - c'est ce que j'aime. J'inclus généralement les tests unitaires dans les fichiers eux-mêmes, et de cette façon je peux encapsuler mes tests unitaires dans cette instruction if.
Je me

34

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.


3
C'est une excellente solution si vous êtes en mesure de le faire. J'ai récemment dû commencer à travailler avec des hébergeurs partagés et j'ai découvert que l'un des nombreux désagréments était que tout devait être à l'intérieur de la docroot.
Beau Simensen

3
Dans chaque fournisseur d'hébergement avec lequel j'ai travaillé, j'avais toujours accès à (exactement) un niveau au-dessus de la racine du document.
Eran Galperin

3
Chez certains hôtes (y compris mon hôte actuel), vous pouvez pointer votre domaine vers le dossier de votre choix.
Dinah le

1
C'est aussi une bonne alternative .. en utilisant preg_match -> if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Alerte de sécurité de l'appliance - Accès direct interdit! Votre adresse IP a été enregistrée! <h3> '); // Arrêter la poursuite de l'exécution}
MarcoZen

Cette url devzone.zend.com/node/view/id/70 est maintenant un 404. La réponse doit inclure le code qui a été utilisé à l'origine à partir de cette URL inexistante.
Funk Forty Niner

31

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é.



26

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>

Il vaudrait mieux utiliser .inc.php je crois, et c'est une pratique courante
Lis

14

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.


8

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.


7

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

7

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;
    }
}

3

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

2
Ceci est dangereux si register_globals est activé.
jmucchiello

25
PHP est dangereux si register_globals est activé.
David Precious

3

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.


Après un long moment, je veux juste commenter que le modèle que vous décrivez ci-dessus s'appelle le modèle MVC (Model - View - Controller). Si vous le souhaitez, consultez Google et ajoutez quelques informations supplémentaires à votre réponse. MVC prend également en charge non seulement Ruby on Rails et les applications ASP.NET, mais aussi PHP (voir Lavarel, CakePHP).

3

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.


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

3

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();

2

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.


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

if (preg_match ("~ globalfile \ .php ~ i", $ _SERVER ['PHP_SELF'])) {die ('<h3 style = "color: red"> Alerte de sécurité de l'appliance - Accès direct interdit! Votre adresse IP a été enregistrée ! <h3> '); // Arrêter la poursuite de l'exécution} whre ~ est le délimiteur
MarcoZen

1

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("...");
}

1

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.


où il est censé taper l'URL en mode CLI?
Votre bon sens

C'est juste pour empêcher le lancement du script php / inlude en mode cli. Peut être utile dans un projet avec plusieurs développeurs.
Ka.

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

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

1

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.

0

Faites quelque chose comme:

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

Cela ne l'empêchera pas d'être chargé dans le navigateur.
UnkwnTech

0

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 comprends que tous les en-têtes de serveur HTTP_ * ne sont pas dignes de confiance, il vaut donc mieux ne pas utiliser cette méthode.
andreszs

0

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.


0

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


0

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.


0

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
}

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

fera le travail en douceur


2
Copiez coller de CodeIgnitor. C'est cool mais ça ne fait rien par lui-même. Le BASEPATH const est défini dans un index.phpfichier qui se trouve au bas de l'arborescence. CI réécrit les URL afin qu'il n'y ait pas besoin d'accéder aux scripts directement de toute façon.
jimasun

Je sais que ce n'est pas nécessaire, mais si quelqu'un essaie de le faire
Varshaan

0

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.');
    }

2
Je ne comprends pas vraiment comment cela peut empêcher l'accès direct
Adam Lindsay
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.