Я видел в потоке и видел в некоторых рамках, что использование ниже структуры рекомендуется. Может кто-нибудь объяснить, почему, с точки зрения безопасности (если вы можете объяснить это, было бы полезно оценить)? Есть ли другие преимущества этого?
РЕДАКТИРОВАТЬ:
Имеет ли это эффект, если сервер был взломан?
Идея состоит в том, что только объекты, которые должны быть доступны пользователю, помещаются в public_html , чтобы случайные люди в Интернете не могли получить доступ к случайным фрагментам вашего кода или данных, если они угадали правильный URL.
Обычно это делается для того, чтобы иметь общедоступную папку внутри приложения, которая затем символически привязана к public_html или ниже, и фактически не разделяет приложение на две части.
В предыдущих проектах клиент использовал свои файлы конфигурации вне папки public_html . Это возможно, но при включении файлов PHP я просто сделал что-то вроде этого
<?php require_once('/home/brandon/config/config.php'); ?>
Вместо этого:
<?php require_once('/home/brandon/public_html/config.php'); ?>
Я боролся с этой проблемой. Управляя большим количеством веб-сайтов, я решил разместить свои php-библиотеки в поддире в общей папке и ссылаться на них, используя относительный путь в моих включенных. Таким образом, мне не нужно менять какие-либо пути для запуска / тестирования их на моем сервере разработки и в производстве.
В прошлом году один из моих клиентских сайтов начал получать взломанные повторно. Хакеры каким-то образом получили доступ к учетной записи FTP и вставляли свои собственные файлы (включая php), а также заменяли некоторые и удаляли других и создавали каталоги. Все это, несмотря на то, что все диски равны 755 и файлы до 644 перм. Конечно, если у них есть учетная запись FTP, это игра, попробуйте еще раз.
Они взломали сайт 6 раз (что я знаю). Это единственный из моих сайтов, которые когда-либо были взломаны! Я рассматриваю вопрос о том, есть ли смысл переместить мои файлы php-библиотеки за пределы общей папки (для этого сайта, в любом случае). Я подтвердил, что ни один из этих файлов не может быть загружен / просматриваться через браузер (получить пустую страницу и страницу с пустым представлением).
Я также использую SFTP, защищенные пароли и защищаю от атак SQL-инъекций.
Хакеры использовали сторонние трещины службы, чтобы попасть на этот сайт, по крайней мере, один раз. Каждый раз они делают что-то другое в / с сайтом. Этот сайт использует только PayPal, поэтому данные о клиентах не хранятся на месте. Они заменили адрес электронной почты, отправленный в PayPal, чтобы идентифицировать учетную запись продавца для оплаты платежа, но клиент никогда, похоже, не может фактически заплатить (у хакера, вероятно, нет учетной записи PayPal).
Одна оставшаяся возможность – это ключевой регистратор на своем компьютере. Через пару дней я положу это через звонок.
Конечно, хостинг-провайдер не будет иметь ничего общего с этой проблемой. Они выполнили «сканирование», которое обнаружило только 5 из 21 грязных файлов (не считая каталогов), созданных, замененных или удаленных хакером. Они продолжают говорить, что я плачу за услугу «блокировки сайта», которая кажется совершенно бесполезной и полной тратой денег.
Мне бы очень хотелось найти всеобъемлющую «анти-хакерскую кулинарную книгу», в которой подробно рассматриваются вопросы безопасности в ситуациях с общим хостингом, и есть много хороших примеров. Что-то подобное существует?