Привет, спасибо всем за то, что вы прочитали мой вопрос.
Я некоторое время работал над веб-программой PHP и задавался вопросом, какие меры следует принять для защиты источника, прежде чем размещать его на реальном сервере. Источник не распространяется, к нему обращаются через веб-сайт (пользователи регистрируются на веб-сайте, чтобы использовать его).
Сначала я хотел бы защитить исходные файлы php от поиска и загрузки. Я не использую фреймворк, только php и все файлы находятся в домашнем каталоге как index.php. Я читал, и кажется, что robots.txt не очень эффективен для скрытия. Я столкнулся с некоторыми сообщениями о рекомендациях .htaccess, но я часто думал, что это для защиты файлов в каталоге с паролем, поэтому не уверен, есть ли способ сделать его htaccess подходящим для веб-приложения.
Во-вторых, я хотел бы защитить исходные файлы в том случае, если кто-то получает к ним доступ (либо находит их, либо загружает их, либо администратор sys, у которого есть готовый доступ к серверу). Я думал об шифровании источника с чем-то вроде ioncube. У моего хоста также есть GnuPG [который я не знаю, никаких мыслей об этом по сравнению с ioncube?]
Я не знаком с защитой источника, поэтому любые идеи были бы приятными, и, конечно же, спасибо вам большое 🙂
Просто убедитесь, что ваш веб-сервер настроен правильно обрабатывать файлы .php и что все файлы имеют правильное расширение .php (не .php.inc или подобное)
Пока ваш сервер выполняет PHP, никто не может загрузить его исходный код (игнорируя любые дыры в вашем коде, что является другой темой)
Было время, когда обычно mystuff.php.inc файлы, связанные с mystuff.php.inc – это плохая идея. Скажите, что ваш сайт находится на «example.com», и вы сохраняете конфигурацию своей базы данных в файле config.php.inc – если кто-то догадывается об этом URL-адресе, они могут запросить http://example.com/config.php.inc и получить вашу базу данных войти в обычный текст ..
Рекомендуется хранить конфигурацию и другие библиотеки в одной директории, так как bisko ответил – так что у вас есть структура каталогов, такая как ..
/var/example.com: include/ config.php helper_blah.php webroot/ index.php view.php
Таким образом, даже если конфигурация вашего веб-сервера будет запутана и начнет обслуживать .php файлы в виде обычного текста, это будет плохо, но по крайней мере вы не будете объявлять данные своей базы данных миру.
Что касается шифрования файлов, я не думаю, что это хорошая идея. Файлы должны быть незашифрованы для Apache (или любого другого сервера, который вы используете) могут получить к ним доступ. Если Apache может получить к нему доступ, ваш системный администратор тоже может ..
Я не думаю, что шифрование является решением ненадежного системного администратора.
Хорошо для вашего первого момента, это безопасность веб-сервера, на которую вы должны искать помощь по serverfault. В основном вы использовали бы защищенный / заблокированный каталог для этого или доступ к файлам в виртуальном каталоге через веб-службу.
Для вас второй момент, вы бы использовали обфускатор для этого, который будет защищать ваш источник, но помните, что если они получают файл, вы можете сделать это только для его защиты. Если они действительно заинтересованы, они получат то, что хотят.
Первый шаг, который вы должны предпринять, – вынуть все ненужные файлы из корня веб-сайта и поместить их в другое место и оставить только файлы, вызываемые из Интернета.
Например, если у вас есть эта настройка:
/var/htdocs/mysexydomain.com/root/config.php /var/htdocs/mysexydomain.com/root/db.class.php /var/htdocs/mysexydomain.com/root/index.php /var/htdocs/mysexydomain.com/root/samplepage1.php
Возьмите все файлы на один уровень выше, чтобы получить
/var/htdocs/mysexydomain.com/includes/config.php /var/htdocs/mysexydomain.com/includes/db.class.php #see the includes dir? :) /var/htdocs/mysexydomain.com/root/index.php /var/htdocs/mysexydomain.com/root/samplepage1.php