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

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

$including = true;

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

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

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

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

Самый простой способ для типовой ситуации «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);
?>

Сделайте что-нибудь вроде:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

или иначе

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

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

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

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

Я нашел это неизменяемое решение только для php, которое работает как с 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.

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

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

Разместите здесь свой другой HTML-код

<? } ?>

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

Вы также можете попробовать переименовать документ, к которому вы не хотите, чтобы люди могли получить к нему доступ. Вы можете, например, переименовать его в 47d8498d3w.php. Просто придумайте что-нибудь, что люди, скорее всего, не будут набирать в качестве http-запроса. Если вы включите файл с SSI или PHP, пользователь все равно не сможет увидеть имя документа.

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

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

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

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

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

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

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

define(A,true);

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

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

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

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

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

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

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

А еще есть .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();

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

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. Учебник здесь.

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

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-сервер получит к ним доступ, в то время как горячие ссылки запрещены для пользователя.
• Даже если конфигурация доступа к файловой системе веб-сервера не была выполнена должным образом, этот метод предотвратит случайное открытие доступа к этим файлам.

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

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

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

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

Я не нашел предложения с .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.');
    }

Вы можете использовать стиль phpMyAdmin:

/**
 * block attempts to directly run this script
 */
if (getcwd() == dirname(__FILE__)) {
    die('Attack stopped');
}

Перенаправить из этого файла на другую страницу. (например, index.html)

.htaccess:

Redirect 301 LINK_TO_YOUR_PHP LINK_TO_INDEX.HTML

Я хотел ограничить доступ к файлу 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;
    }
}

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

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

<?php

function a() {
    // function body
}

function b() {
    // function body
}

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

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

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