Запретить прямой доступ к файлу php

У меня есть php-файл, который я буду использовать исключительно для включения. Поэтому я хотел бы выдать ошибку вместо того, чтобы выполнить ее, когда к ней обращаются напрямую, введя URL вместо того, чтобы быть включенным.

В основном мне нужно сделать проверку следующим образом в файле php:

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

Есть простой способ сделать это?

Самый простой способ для общей ситуации «приложение PHP, работающее на сервере Apache, которым вы можете или не можете полностью управлять», - это поместить ваши включения в каталог и запретить доступ к этому каталогу в вашем файле .htaccess. Чтобы избавить людей от проблем с Google, если вы используете Apache, поместите его в файл с именем «.htaccess» в каталоге, который вам не нужен:

Deny from all

Если вы на самом деле имеете полный контроль над сервером (в наши дни это более распространено даже для небольших приложений, чем когда я впервые писал этот ответ), лучший способ - разместить файлы, которые вы хотите защитить, за пределами каталога, из которого обслуживается ваш веб-сервер. , Поэтому, если ваше приложение включено /srv/YourApp/, настройте сервер для обслуживания файлов /srv/YourApp/app/и вставьте включенные файлы /srv/YourApp/includes, чтобы буквально не было URL-адресов, которые могли бы получить к ним доступ.

Добавьте это на страницу, которую хотите включить только

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

затем на страницах, которые включают его добавить

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

У меня есть файл, который мне нужно действовать по-разному, когда он включен по сравнению с, когда к нему обращаются напрямую (в основном, print()против return()) Вот некоторый модифицированный код:

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

Доступ к файлу всегда является включенным файлом, поэтому == 1.  

Лучший способ предотвратить прямой доступ к файлам - разместить их вне корня документа веб-сервера (обычно на один уровень выше). Вы по-прежнему можете включать их, но нет возможности доступа к ним через HTTP-запрос.

Я обычно иду до конца и помещаю все свои PHP-файлы вне корневого каталога документа, кроме файла начальной загрузки - одиночного index.php в корневом каталоге документа, который начинает маршрутизацию всего сайта / приложения.

1: Проверка количества включенных файлов

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

Логика: PHP завершается, если минимальное число включений не выполнено. Обратите внимание, что до PHP5 базовая страница не считается включаемой.

2: определение и проверка глобальной константы

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

Логика: если константа не определена, то выполнение не начнется с базовой страницы, и PHP прекратит выполнение.

Обратите внимание, что ради переносимости между обновлениями и будущими изменениями использование этого метода аутентификации модульным значительно уменьшит накладные расходы при кодировании, поскольку изменения не нужно будет жестко кодировать для каждого отдельного файла.

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

Таким образом, дополнительный код может быть добавлен checkdefined.php для регистрации и аналитических целей, а также для генерации соответствующих ответов.

Кредит, где кредит должен: блестящая идея переносимости пришла из этого ответа .

3: Удаленная авторизация адреса

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

Недостатком этого метода является изолированное выполнение, если только токен сеанса не предоставлен с внутренним запросом. Проверьте через адрес обратной связи в случае конфигурации с одним сервером или белый список адресов для многосерверной или серверной инфраструктуры с балансировкой нагрузки.

4: авторизация токена

Как и в предыдущем методе, можно использовать GET или POST для передачи токена авторизации во включаемый файл:

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

Очень грязный метод, но, возможно, самый безопасный и универсальный одновременно, при правильном использовании.

5: Конфигурация веб-сервера

Большинство серверов позволяют вам назначать разрешения для отдельных файлов или каталогов. Вы можете поместить все свои включения в такие ограниченные каталоги и настроить сервер на их запрет.

Например, в APACHE конфигурация хранится в .htaccessфайле. Учебник здесь .

Однако обратите внимание, что специфичные для сервера конфигурации не рекомендуются мной, поскольку они плохо переносятся между различными веб-серверами. В таких случаях, как системы управления контентом, где алгоритм deny сложен или список запрещенных каталогов довольно велик, это может сделать сеансы реконфигурации довольно ужасными. В конце концов, лучше всего справиться с этим в коде.

6: Размещение включает в безопасном каталоге за пределами корня сайта

Наименее предпочтительный из-за ограничений доступа в серверных средах, но довольно мощный метод, если у вас есть доступ к файловой системе.

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

Логика:

• Пользователь не может запросить какой-либо файл за пределами htdocsпапки, поскольку ссылки будут выходить за рамки адресной системы сайта.
• Php-сервер напрямую обращается к файловой системе и, следовательно, может обращаться к файлам на компьютере, как это делает обычная программа с необходимыми привилегиями.
• Поместив включаемые файлы в этот каталог, вы можете гарантировать, что php-сервер получит к ним доступ, в то время как горячая ссылка запрещена для пользователя.
• Даже если настройка доступа к файловой системе веб-сервера не была выполнена должным образом, этот метод предотвратит случайное обнародование этих файлов.

Пожалуйста, извините мои неортодоксальные соглашения о кодировании. Любые отзывы приветствуются.

Альтернативой (или дополнением) решению Чака было бы запретить доступ к файлам, соответствующим определенному шаблону, добавив что-то подобное в ваш файл .htaccess.

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

На самом деле мой совет - использовать все эти лучшие практики.

• Поместите документы вне веб-корня ИЛИ в каталог, к которому веб-сервер не имеет доступа И
• Используйте определение в ваших видимых документах, которые проверяют скрытые документы:

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

Таким образом, если файлы становятся неуместными (ошибочная операция ftp), они все еще защищены.

Однажды у меня была эта проблема, решенная с помощью:

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

но идеальным решением является размещение файла вне корневого каталога документов веб-сервера, как упоминалось в другом ответе.

Вам лучше создать приложение с одной точкой входа, т.е. все файлы должны быть доступны из index.php

Поместите это в index.php

define(A,true);

Эта проверка должна выполняться в каждом связанном файле (через require или include)

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

Я хотел ограничить доступ к файлу PHP напрямую, но также иметь возможность вызывать его через jQuery $.ajax (XMLHttpRequest). Вот что сработало для меня.

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

Самый простой способ - установить переменную в файле, который вызывает include, например:

$including = true;

Затем в файле, который включен, проверьте переменную

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

Помимо способа .htaccess, я видел полезный шаблон в различных фреймворках, например в ruby ​​на рельсах. У них есть отдельный каталог pub / в корневом каталоге приложения, а каталоги библиотеки живут в каталогах на же уровня, что и pub /. Примерно так (не идеально, но вы поняли):

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

Вы настроили свой веб-сервер на использование pub / в качестве корня документа. Это обеспечивает лучшую защиту ваших сценариев: хотя они могут обращаться к корневому каталогу документа для загрузки необходимых компонентов, доступ к компонентам из Интернета невозможен. Другое преимущество, помимо безопасности, заключается в том, что все в одном месте.

Эта настройка лучше, чем просто создание проверок в каждом включенном файле, потому что сообщение «доступ запрещен» является подсказкой для злоумышленников, и это лучше, чем конфигурация .htaccess, потому что она не основана на белом списке: если вы испортили расширения файла он не будет виден в каталогах lib /, conf / etc.

Какая Joomla! do определяет Константу в корневом файле и проверяет, определена ли она во включаемых файлах.

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

или еще

Можно хранить все файлы вне досягаемости http-запроса, размещая их вне каталога webroot, как рекомендует большинство фреймворков, таких как CodeIgniter.

или даже поместив файл .htaccess в папку include и правила записи, вы можете запретить прямой доступ.

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

Мой ответ несколько отличается в подходе, но включает в себя многие ответы, представленные здесь. Я бы порекомендовал многоплановый подход:

1. Ограничения .htaccess и Apache наверняка
2. defined('_SOMECONSTANT') or die('Hackers! Be gone!');

ОДНАКОdefined or die подход имеет ряд недостатков. Во-первых, это реальная боль в допущениях для тестирования и отладки. Во-вторых, если вы передумаете, это будет ужасающе, ошеломляюще скучным рефакторингом. "Найти и заменить!" ты говоришь. Да, но насколько вы уверены, что везде написано одно и то же, хммм? Теперь умножьте это на тысячи файлов ... oO

И тогда есть .htaccess. Что произойдет, если ваш код распространяется на сайты, где администратор не так скрупулезен? Если вы полагаетесь только на .htaccess для защиты своих файлов, вам также понадобятся: а) резервная копия, б) коробка с салфетками, чтобы высушить ваши слезы, в) огнетушитель для тушения пламени во всей ненависти от людей используя ваш код

Итак, я знаю, что вопрос требует «самого простого», но я думаю, что это требует более «защитного кодирования».

Я предлагаю следующее:

1. Перед любым из ваших сценариев require('ifyoulieyougonnadie.php');(а не include() в качестве замены defined or die)

2. В ifyoulieyougonnadie.php, сделать некоторые логики вещей - проверку для различных констант, вызывая сценарий, локальное тестирование и такой - а затем реализовать ваши die(), throw new Exception, 403, и т.д.

   Я создаю свой собственный фреймворк с двумя возможными точками входа - основной index.php (фреймворк Joomla) и ajaxrouter.php (мой фреймворк) - поэтому в зависимости от точки входа я проверяю разные вещи. Если запросifyoulieyougonnadie.php не приходит из одного из этих двух файлов, я знаю, что махинации предпринимаются!

   Но что, если я добавлю новую точку входа? Не беспокойся. Я просто меняюifyoulieyougonnadie.php и сортирую, плюс нет «найди и замени». Ура!

   Что если я решил переместить некоторые из моих сценариев для создания другой среды, которая не имеет одинаковых констант defined()? ... Ура! ^ _ ^

Я обнаружил, что эта стратегия делает разработку намного веселее и намного меньше:

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

Если точнее, вы должны использовать это условие:

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

get_included_files () возвращает индексированный массив, содержащий имена всех включенных файлов (если файл выполняется как beign, то он был включен, и его имя находится в массиве). Таким образом, когда файл доступен напрямую, его имя является первым в массиве, все остальные файлы в массиве были включены.

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

Поместите код выше в верхней части вашего включенного файла PHP.

например:

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

Следующий код используется в Flatnux CMS ( http://flatnux.altervista.org ):

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

Я нашел это php-only и неизменное решение, которое работает как с http, так и с cli:

Определить функцию:

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

Вызовите функцию в файле, к которому вы хотите запретить прямой доступ:

forbidDirectAccess(__FILE__);

Большинство из приведенных выше решений этого вопроса не работают в режиме 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");
  }
?>

Хранение ваших включаемых файлов вне каталога, доступного через Интернет, упоминалось несколько раз и, по возможности, является хорошей стратегией. Тем не менее, еще один вариант, который я еще не видел, был упомянут: убедитесь, что ваши включаемые файлы не содержат исполняемый код . Если ваши включаемые файлы просто определяют функции и классы и не имеют никакого другого кода, они просто создадут пустую страницу при прямом доступе.

Разумеется, разрешите прямой доступ к этому файлу из браузера: он ничего не сделает . Он определяет некоторые функции, но ни одна из них не вызывается, поэтому ни одна из них не запускается.

<?php

function a() {
    // function body
}

function b() {
    // function body
}

То же самое относится и к файлам, которые содержат только классы PHP и ничего больше.

По-прежнему рекомендуется хранить файлы вне веб-каталога, где это возможно.

• Вы можете случайно отключить PHP, и в этом случае ваш сервер может отправлять содержимое файлов PHP в браузер вместо того, чтобы запускать PHP и отправлять результат. Это может привести к утечке кода (включая пароли базы данных, ключи API и т. Д.).
• Файлы в веб-каталоге сидят на корточках по URL-адресам, которые вы можете использовать для своего приложения. Я работаю с CMS, у которой не может быть вызвана страница system, потому что это будет конфликтовать с путем, используемым для кода. Я нахожу это раздражающим.

Сделать что-то вроде:

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

Вы можете использовать следующий метод ниже, хотя, у него есть недостаток, потому что он может быть подделан, за исключением случаев, когда вы можете добавить еще одну строку кода, чтобы убедиться, что запрос поступает только с вашего сервера либо с помощью Javascript. Вы можете поместить этот код в раздел «Тело» своего HTML-кода, чтобы там отображалась ошибка.

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

Поместите другой код HTML здесь

<? } ?>

Завершите это так, чтобы вывод ошибки всегда отображался в разделе body, если вы хотите, чтобы это было так.

Я предлагаю не использовать $_SERVERпо соображениям безопасности.
Вы можете использовать переменную, как $root=true;в первом файле, который включал другой.
и использовать isset($root)в начале второго файла, который будет включен.

Что вы также можете сделать, это защитить каталог паролем и хранить там все свои php-скрипты, разумеется, кроме файла index.php, поскольку во время включения пароль не потребуется, поскольку он потребуется только для доступа по http. он также предоставит вам возможность доступа к вашим сценариям, если вы захотите, поскольку у вас будет пароль для доступа к этому каталогу. вам потребуется настроить файл .htaccess для каталога и файл .htpasswd для аутентификации пользователя.

ну, вы также можете использовать любое из предложенных выше решений, если вам кажется, что вам не нужен обычный доступ к этим файлам, потому что вы всегда можете получить к ним доступ через cPanel и т. д.

Надеюсь это поможет

Самый простой способ - хранить ваши включения вне веб-каталога. Таким образом, сервер имеет доступ к ним, но не имеет внешнего компьютера. Единственным недостатком является необходимость иметь доступ к этой части вашего сервера. Плюс в том, что он не требует настройки, настройки или дополнительного кода / нагрузки на сервер.

Я не нашел предложения с .htaccess настолько хорошими, потому что он может заблокировать другой контент в этой папке, к которому вы, возможно, захотите разрешить пользователю доступ, вот мое решение:

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

сделает работу гладко

Добавлено упомянутое ранее решение с проверкой версии PHP:

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