Как защитить файлы php
Все программные продукты для защиты PHP-скриптов подразделяются на две категории: требующие установки на сервер дополнительных модулей и работающие с обычной конфигурацией web-серверов. Первые более надежны в плане безопасности, так как переводят PHP-скрипты из текстового вида в специальный двоичный-код, но требуют доступа к серверу с правами администратора. Вторые могут работать практически на всех хостингах с поддержкой PHP, в том числе и бесплатных, но не представляют большой сложности для взлома. В отдельную подгруппу можно выделить обфускаторы исходного кода, не использующие шифрование или сжатие.
Защиты на уровне сервера:
Zend Encoder / Zend SafeGuard Suite - наиболее популярная коммерческая защита, модули для поддержки Zend обычно установлены на всех платных хостингах. Zend предоставляет привязку скриптов к доменам и ip, установку времени триальной работы скриптов и мощную обфускацию. Поддерживаются все операционные системы. В публичном доступе имеется несколько вариантов утилит для снятия Zend'а, все они представляют собой модифицированный PHP 4-й и 5-й версии. Старые версии Zend'а снимаются без проблем, в последних возникают сложности из-за обфускации исходного кода.
NuSphere NuCoder. Новая, активно развивающаяся коммерческая защита. На уровне собственных API предоставляет взаимодействие с защищаемыми скриптами, поддерживаются операционные системы Windows и Linux. Вследствие малой распространенности не устанавливается на обычных виртуальных хостингах, но вполне может быть установлена пользователями на выделенных серверах. Публичных декодеров нет.
SourceGuardian for PHP. Коммерческая защита, практически не встречается, на вирутальных хостингах не устанавливается. Позволяет устаналивать триальный срок работы скриптов с проверкой даты по внешним серверам точного времени, делать привязку защищаемых скриптов к серверам, ip-адресу, MAC-адресу сетевой карты, причем эти данные используются для расшифровки. Поддерживаются все операционные системы. Публичных декодеров нет.
phpSHIELD. Прототип SourceGuardian for PHP. После слияния двух разработчиков перестал развиваться как самостоятельный продукт. Основной функционал тот же самый, публичных декодеров нет.
ionCube PHP Encoder. Второй по популярности коммерческий продукт для защиты скриптов. После появления публичных декодеров для Zend стал все чаще использоваться и устанавливаться на виртуальных хостингах. Позволяет шифровать не только скрипты, но и шаблоны, xml-документы, изображения, бинарные файлы. Привязывает защищенные файлы к серверам, есть мощный обфускатор, поддерживаются все операционные системы. Публичных декодеров нет, но в некоторых случаях снимается deZender'ом.
PHTML Encoder. Малораспространенная коммерческая система защиты, предоставляет обычный функционал для продуктов такого типа, работает под всеми операционными системами. За отдельную плату можно приобрести исходные коды защиты и модифицировать их под свои нужды. Публичных декодеров нет.
DWebEncoder. Экзотическая защита под Windows, предназначенная для создания скриптовых презентаций и каталогов на компакт-дисках. В установленном виде представляет собой что-то типа самостоятельного web-сервера, на котором исполняются закодированные php-скрипты. Публичных декодеров нет.
PHP Compact. Защита скорее теоретическая, чем практическая. Разрабатывалась на одном из отечественных форумов, но похоже дальше авторских релизов дело не продвинулось. Декодеров нет, впрочем как и защищенных скриптов.
PHPCoder / eAccelerator. Дополнение с открытым кодом к старинным php-акселераторам Turck MMCache и eAccelerator. Переводит скрипты в байт-код с целью повышения скорости их выполнения. Есть версии модулей под Windows и Linux. Публичных декодеров нет, но возможно открытый код проекта как-то поможет в изучении.
Защиты на уровне исходного кода:
PHP LockIt!. Популярная коммерческая защита, встречается очень часто, в основном на скриптах зарубежных разработчиков. Позволяет устанавливать триальный срок работы скриптов, привязку к доменам и ip-адресам, сжимает скрипты штатными средствами php (gzinflate). Единственная сложность - хороший обфускатор. Различные версии защиты отличаются только модификацией модуля распаковки. Легко снимается как в ручном, так и в автоматическом режиме. Без обфускатора снимается в точности до исходного кода, с обфускатором требует дополнительной обработки.
CNCrypto. В свободном доступе нет даже демо-версии, анализ проводился по защищенным скриптам. Навесной модуль сложности в распаковке не представляет, защита держится только на хорошей обфускации исходного кода.
PHPCipher. Защита представляет собой он-лайн сервис. На сайт загружается архив с вашими скриптами и обратно скачивается уже защищенный. Платная лицензия позволяет подписывать защищенные скрипты своими данными и использовать для коммерческих целей. Бесплатная лицензия допускает использование только для личных нужд. Сама защита представляет собой защищенный Zend'ом php-модуль, который подключается к защищенным скриптам. После deZend'а модуля защиты и получения из него всех необходимых констант снимается полностью до исходного кода. Функции обфускатора нет.
ByteRun Protector for PHP. Коммерческий продукт, в зависимости от типа лицензии позволяет защищать скрипты как на уровне сервера, так и на уровне исходного кода. Серверная защита со стандартными возможностями, ничего особенного нет. Защита на уровне скриптов снимается очень легко автоматически и вручную. Публичного декодера на серверную версию нет.
SourceCop PHP Protector. Очень популярная у отечественных разработчиков защита. Представляет собой сильно замусоренный пустым кодом модуль защиты, который подключается через include к защищенным скриптам. Алгоритм декодирования очень простой, не вызывает никаких сложностей в ручном и автоматическом снятии. Во всех случаях снимается полностью до исходного кода, функции обфускатора нет. Есть небольшие особенности для частных случаев декодирования, но здесь они описаны не будут.
CodeLock. Еще одна популярная защита, отличный пример безграмотного программирования. Представляет собой приложение на php, позволяет кодировать как сами скрипты, так и результат их работы в браузере средствами javascript. Скрипты можно защищать паролем, но из-за бездарной реализации пароль легко узнать даже не снимая навесную защиту. Модуль защиты представляет собой замусоренный пустым кодом php-скрипт, который подключается к защищаемым скриптам. Алгоритм защиты очень простой, снимается полностью до исходного кода. Функции обфускации нет.
TrueBug PHP Encoder, с недавнего времени TrueBug PHP Obfuscator & Encoder. Очень интересный протектор для исследования. До версии 1.0.2 использовались стандартные средства php для gzip-компрессии, начиная с версии 1.0.3 авторами был разработан собственный алгоритм сжатия. В новом продукте TrueBug PHP Obfuscator & Encoder добавлена функция обфускации и оптимизации исходного кода. Единственное слабое место защиты - неизменный алгоритм декодирования скриптов, но сам алгоритм меняется для каждой версии защиты. После разбора защиты снимается легко в точности до исходного кода, естественно при условии что не был использован обфускатор.
Zorex PHP CryptZ. Защита, как и CodeLock, представляет собой приложение на php, для его работы требуется база MySQL. Модуль защиты - подключаемый скрипт на php, зашифрованный в несколько слоев. После разбора алгоритма снимается очень легко в точности до исходного кода. Функции обфускатора нет.
Free PHP Encoder. Бесплатный он-лайновый сервис для кодирования php-скриптов. Модуль защиты представляет собой подключаемый php-скрипт, накрытый Zend'ом, который надо скачать с сайта. После снятия Zend'а и разбора алгоритма защита легко снимается полностью до исходного кода. Алгоритм защиты неизменный, функции обфускатора нет.
gencoder. Скрипт на php, кодирование примитивное, стандартный base64. Большего внимания не заслуживает и практического интереса не представляет.
FREE Encrypted PHP. Бесплатный он-лайновый шифровщик файлов, выполняющий привязку к серверу и ограничение по времени работы скрипта. К зашифрованным скриптам подключается модуль расшифровки, накрытый ionCube. После открытия алгоритма расшифровки легко снимается.
Free Online PHP Obfuscator. Бесплатный он-лайновый шифровщик файлов, несмотря на слово "obfuscator" в названии, дополнительно сжимает и шифрует скрипты. Внешняя шифровка сложности в снятии не представляет, основная защита держится на обфускации текстовых строк и имен переменных.
Обфускаторы:
Особого интереса в плане изучения не представляют, все работают по одинаковому принципу: замена названий переменных на набор случайных символов, удаление комментариев, переносов строк и пробелов, использованных для форматирования кода. К ним относятся GridinSoft PHP Processor, Semantic Designs Obfuscator, PHP Defender, Raizlabs PHP Obfuscator, Obfusc, POBS, PHP UnReader, Code Eclipse и другие. По деобфускации различных скриптов есть полезная статья статья.
Для определения чем защищены скрипты можете воспользоваться программой PCL's PHPiD. По всем вопросам "а где взять декодеры?" и "а как сломать?" обращайтесь к поисковым системам.
У меня есть 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
Добавьте это к странице, которую вы хотите, чтобы только она была включена:
<?php
if(!defined('MyConst'))
die('Прямой доступ запрещен');
>
?>
затем на страницах, включающих его, добавьте:
<?php
define('MyConst', TRUE);
?> .
Ответ 3
1. Проверка количества включенных файлов
if( count(get_included_files()) == ((version_compare(PHP_VERSION, '5.0.0', '>='))?1:0) )
exit('Ограниченный доступ');
>
Логика: PHP завершает работу, если не соблюдается минимальное количество включений. Обратите внимание, что до PHP5 базовая страница не считалась включаемой.
2: Определение и проверка глобальной константы
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
.htaccess и ограничения Apache
defined('_SOMECONSTANT') or die(' Хакеры! Уходите!');
Перед любым из ваших скриптов использовать require('ifyoulieyougonnadie.php'); ( не include() и в качестве замены defined or die )
В ifyoulieyougonnadie.php , сделайте некоторые логические вещи - проверьте различные константы, вызывающий скрипт, тестирование localhost и т. д. - а затем реализуйте свой die(), throw new Exception, 403 и т. д.
Ответ 5
Ответ 6
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Рассмотрим следующий пример, в котором пользователь создал скрипт, удаляющий файл из его домашней директории. Предполагается ситуация, когда веб-интерфейс, написанный на PHP , регулярно используется для работы с файлами, и настройки безопасности позволяют удалять файлы в домашнем каталоге.
<?php
// Удаление файла из домашней директории пользователя
$username = $_POST [ 'user_submitted_name' ];
$userfile = $_POST [ 'user_submitted_filename' ];
$homedir = "/home/ $username " ;
unlink ( " $homedir / $userfile " );
echo "Файл был удалён!" ;
?>
<?php
// Удаление любого файла, доступного из PHP-скрипта.
// В случае, если PHP работает с правами пользователя root:
$username = $_POST [ 'user_submitted_name' ]; // "../etc"
$userfile = $_POST [ 'user_submitted_filename' ]; // "passwd"
$homedir = "/home/ $username " ; // "/home/../etc"
unlink ( " $homedir / $userfile " ); // "/home/../etc/passwd"
echo "Файл был удалён!" ;
?>
- Ограничить доступ пользователя, с правами которого работает веб-сервер с PHP .
- Проверять все данные, вводимые пользователем.
<?php
// Удаление любого файла, к которому имеет доступ пользователь,
// под которым запущен PHP.
$username = $_SERVER [ 'REMOTE_USER' ]; // использование авторизации
$userfile = basename ( $_POST [ 'user_submitted_filename' ]);
$homedir = "/home/ $username " ;
$filepath = " $homedir / $userfile " ;
if ( file_exists ( $filepath ) && unlink ( $filepath )) $logstring = " $filepath удалён\n" ;
> else $logstring = "Не удалось удалить $filepath \n" ;
>
$fp = fopen ( "/home/logging/filedelete.log" , "a" );
fwrite ( $fp , $logstring );
fclose ( $fp );
echo htmlentities ( $logstring , ENT_QUOTES );
Однако и такая проверка не учитывает все возможные ситуации. Если система авторизации позволяет пользователям выбирать произвольные логины, взломщик может создать учётную запись вида "../etc/" и система опять окажется уязвимой. Исходя из этого, вам может понадобиться более строгая проверка:<?php
$username = $_SERVER [ 'REMOTE_USER' ]; // использование авторизации
$userfile = $_POST [ 'user_submitted_filename' ];
$homedir = "/home/ $username " ;
$filepath = " $homedir / $userfile " ;
if (! ctype_alnum ( $username ) || ! preg_match ( '/^(?:[a-z0-9_-]|\.(?!\.))+$/iD' , $userfile )) die( "Неправильное имя пользователя или файл" );
>
В зависимости от используемой вами операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением .ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.
User Contributed Notes 7 notes
(A) Better not to create files or folders with user-supplied names. If you do not validate enough, you can have trouble. Instead create files and folders with randomly generated names like fg3754jk3h and store the username and this file or folder name in a table named, say, user_objects. This will ensure that whatever the user may type, the command going to the shell will contain values from a specific set only and no mischief can be done.
(B) The same applies to commands executed based on an operation that the user chooses. Better not to allow any part of the user's input to go to the command that you will execute. Instead, keep a fixed set of commands and based on what the user has input, and run those only.
For example,
(A) Keep a table named, say, user_objects with values like:
username|chosen_name |actual_name|file_or_dir
--------|--------------|-----------|-----------
jdoe |trekphotos |m5fg767h67 |D
jdoe |notes.txt |nm4b6jh756 |F
tim1997 |_imp_ folder |45jkh64j56 |D
and always use the actual_name in the filesystem operations rather than the user supplied names.
(B)
<?php
$op = $_POST [ 'op' ]; //after a lot of validations
$dir = $_POST [ 'dirname' ]; //after a lot of validations or maybe you can use technique (A)
switch( $op ) case "cd" :
chdir ( $dir );
break;
case "rd" :
rmdir ( $dir );
break;
.
default:
mail ( "[email protected]" , "Mischief" , $_SERVER [ 'REMOTE_ADDR' ]. " is probably attempting an attack." );
>
All of the fixes here assume that it is necessary to allow the user to enter system sensitive information to begin with. The proper way to handle this would be to provide something like a numbered list of files to perform an unlink action on and then the chooses the matching number. There is no way for the user to specify a clever attack circumventing whatever pattern matching filename exclusion syntax that you may have.
Anytime you have a security issue, the proper behaviour is to deny all then allow specific instances, not allow all and restrict. For the simple reason that you may not think of every possible restriction.
Здравствуйте! Не могу определится как лучше реализовать защиту php файлов от прямого доступа:
1) в index.php прописать define('EXEC', true); и в остальных php файлах делать проверку defined('EXEC') || die;
2) .htaccess запретить доступ к php файлам разрешить только index.php
3) ваш вариант
Какой вариант лучше правильней и безопасней?
- Вопрос задан более трёх лет назад
- 5982 просмотра
часто все файлы к которым прямой доступ должен быть запрещен просто выносят за пределы веб директории
/src (здесь весь код приложения)
/web (сюда смотрит apache/nginx)
-- index.php
при такой структуре вынести будет сложнее - папка src у обоих проектов будет одна. придется извращаться как то.
правильная структура для хостингов - внутри директорий доменов создавать дополнительные директори на которые смотрит веб сервер
www
web
puvlic_html
итд
если вы делаете продукт не для одного заказчика а на сто тыщ пользователей, которые должны будут ставить домохозяйки - то лучше в одну папку все.
так же можно весь закрытый код положить в одну папку и добавить
.htaccess внутрь с текстом
deny from all
это также запретит доступ через веб ко всему внутри.
Исходников нет, т.к. реализация очень простая:
Итак, как это делается. Далеко ходить не будем. Рассмотрим как реализовано в CMS Joomla. В файле index.php корневой директории в самом начале есть такая строчка:
А в файлах подключаемых компонетов, модулей и т.д. (тоже в самом начале) такая:
По аналогии также делаем и у себя. Вот код демо-страницы:
файл index.php
Инклюд-файл inc/response.php:
Все очень просто. В коде я привел имя константы и ее значение в том виде, как написано в файлах Joomla. Имя константы и ее значение могут быть любыми, так что желательно придумать свое. Помните только, что имена констант пишутся в верхнем регистре.
Вот и все. по остальным вопросам ответы тоже будут, но позже. Всему свое время :)
5 последних уроков рубрики "PHP"
Фильтрация данных с помощью zend-filter
Когда речь идёт о безопасности веб-сайта, то фраза "фильтруйте всё, экранируйте всё" всегда будет актуальна. Сегодня поговорим о фильтрации данных.
Контекстное экранирование с помощью zend-escaper
Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.
Подключение Zend модулей к Expressive
Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.
Совет: отправка информации в Google Analytics через API
Подборка PHP песочниц
Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.
Читайте также: