Php файлы прямого доступа

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

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

if ( $REQUEST_URL == $URL_OF_CURRENT_PAGE ) die («Прямой доступ к файлу запрещен»);

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

Ответ 1

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

Deny from all .

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

Ответ 2

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

if(!defined(‘MyConst’))

die(‘Прямой доступ запрещен’);

>

?>

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

define(‘MyConst’, TRUE);

?> .

Ответ 3

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

if( count(get_included_files()) == ((version_compare(PHP_VERSION, ‘5.0.0’, ‘>=’))?1:0) )

exit(‘Ограниченный доступ’);

>

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

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

// На базовой странице (прямой доступ):

define(‘_DEFVAR’, 1);

// В включаемых файлах (где прямой доступ запрещен):

defined(‘_DEFVAR’) or exit(‘Ограниченный доступ’);

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

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

// Поместите код в отдельный файл, например, ‘checkdefined.php’:

defined(‘_DEFVAR’) or exit(‘Ограниченный доступ’);

// Замените тот же код в включаемых файлах на:

require_once(‘checkdefined.php’);

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

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

// Вызовите include из базовой страницы (прямой доступ):

$includeData = file_get_contents(«http://127.0.0.1/component.php?auth=token»);

// В включаемых файлах (где прямой доступ запрещен):

$src = $_SERVER[‘REMOTE_ADDR’]; // Получение исходного адреса

$auth = authoriseIP($src); // Алгоритм авторизации

if( !$auth ) exit(‘Ограниченный доступ’);

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

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

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

if($key!=»serv97602″)

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

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

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

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

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

6. Размещение включает в себя безопасный каталог ВНЕ корня сайта.

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

Ответ 4

1. .htaccess и ограничения Apache
2. defined(‘_SOMECONSTANT’) or die(‘ Хакеры! Уходите!’);

1. Перед любым из ваших скриптов использовать require(‘ifyoulieyougonnadie.php’); ( не include() и в качестве замены defined or die )
2. В ifyoulieyougonnadie.php , сделайте некоторые логические вещи — проверьте различные константы, вызывающий скрипт, тестирование localhost и т. д. — а затем реализуйте свой die(), throw new Exception, 403 и т. д.

Ответ 5

Помимо способа .htaccess, я видел полезный паттерн в различных фреймворках, например, в ruby on rails. У них есть отдельный каталог pub/ в корневом каталоге приложения, а каталоги библиотек находятся в каталогах того же уровня, что и pub/. Что-то вроде этого:

app/

|

+—pub/

|

+—lib/

|

+—conf/

|

+—models/

|

+—views/

|

+—controllers/ .

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

Ответ 6

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Как защитить файлы инклюда от прямого вызова?

Сегодняшний урок я скорее всего назвал бы не уроком, а ответом на вопрос, заданном на сайте evgeniypopov.com.

Исходников нет, т.к. реализация очень простая:

Итак, как это делается. Далеко ходить не будем. Рассмотрим как реализовано в CMS Joomla. В файле index.php корневой директории в самом начале есть такая строчка:

А в файлах подключаемых компонетов, модулей и т.д. (тоже в самом начале) такая:

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

Собственно все. В index.php в корневой директории создается константа командой define c именем » _JEXEC» и значением «1». В файлах подключаемых компонетов при помощи функции defined(«_JEXEC») мы проверям существование константы «_JEXEC». Если константа не найдена результат работы функции будет false, в этом случае пишем сообщение «Доступ запрещен» и останавливаем скрипт с помощью функции die (пcевдоним функции exit()).

По аналогии также делаем и у себя. Вот код демо-страницы:
файл index.php

 
Напишите как защитить файлы инклюда от прямого вызова!
 


Ответ:

Инклюд-файл inc/response.php:

defined('_JEXEC') or die('Ай-яй-яй, сюда нельзя!');
echo 'очень просто. Этот ответ находится в "инклюдированном" файле, попробуйте обратиться к нему напрямую, дописав в строке 
браузера /inc/response.php'
?>

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

Вот и все. по остальным вопросам ответы тоже будут, но позже. Всему свое время 🙂

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: www.ruseller.com
Автор: Евгений Стыценков
Урок создан: 21 Июня 2009
Просмотров: 78703
Правила перепечатки

5 последних уроков рубрики «PHP»

• 

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Источник

Как лучше реализовать защиту php файлов от прямого доступа?

Здравствуйте! Не могу определится как лучше реализовать защиту php файлов от прямого доступа:

1) в index.php прописать define(‘EXEC’, true); и в остальных php файлах делать проверку defined(‘EXEC’) || die;
2) .htaccess запретить доступ к php файлам разрешить только index.php
3) ваш вариант

Какой вариант лучше правильней и безопасней?

часто все файлы к которым прямой доступ должен быть запрещен просто выносят за пределы веб директории

/src (здесь весь код приложения)
/web (сюда смотрит apache/nginx)
— index.php

Поддерживаю. Точки входа в отдельную папку, на которую смотрит Webсервер, а исполняемые файлы в других,недоступных webсерверу папках.

riky: кстати я думал над таким вариантом, но я где то читал что это замедляет работу скрипта, не знаю правда это или нет, но вариант очень хороший, спасибо) я почему спросил, потому что 1 вариант используют многие cmc frameworke итд, а как по мне этот вариант не очень)

therealvetalhidden: все cms используют потому что для обычных юзеров так проще + некоторые хостинги могут не поддерживать такой варинат, или усложнит его.
например если вы покупаете хостинг а там в корне просто лежат папки доменов куда надо заливать код
/example.org
— index.php
/example.com
— index.php

при такой структуре вынести будет сложнее — папка src у обоих проектов будет одна. придется извращаться как то.
правильная структура для хостингов — внутри директорий доменов создавать дополнительные директори на которые смотрит веб сервер
www
web
puvlic_html
итд

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

так же можно весь закрытый код положить в одну папку и добавить
.htaccess внутрь с текстом
deny from all
это также запретит доступ через веб ко всему внутри.

Источник