Какие разрешения для PHP скриптов / каталогов? - PullRequest
21 голосов
/ 19 января 2010

Я пытаюсь помочь другу перевести сайт с одного отеля на другой. Старое место уже закрыто, у меня есть только плоский tar-файл из того, что было в нем.

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

Мобильное Java-приложение отправило строку на URL=<HOST>/php/register.php. Этот php-скрипт включал другой php-скрипт (../inc/db_login.php), который подключался к базе данных SQL с помощью $link=mysql_connect(). Другой файл, register.php, выполнил вставку SQL для помещения новых отправленных данных в БД.

Мой вопрос в основном, где я должен разместить эти 2 файла PHP на новом веб-сайте и какие разрешения должны иметь каталоги и файлы?

Старый веб-сервер, очевидно, имел каталоги /php и /inc. Ничего из этого не существует на новом веб-сервере. Должен ли я создать их? Какое разрешение они должны иметь? Я предполагаю, что причиной того, что пароль был в отдельном файле PHP, была безопасность. Возможно, каталоги /php и /inc имеют разные разрешения.

Новый сервер имеет каталоги:

  • /httpdos
  • /httpsdos
  • /cgi-bin
  • /conf (и некоторые другие, вероятно, не имеют значения)

Мои вопросы

  1. Значит ли расширение файла (.php) что-либо для сервера: поскольку PHP-скрипты «включаются» в HTML-код (между <?...?>), нужно ли серверу просматривать суффикс файла или это неактуально? (я так понимаю, что сервер реагирует на <?...?>, конечно)

  2. должен ли публичный файл (register.php в моем случае) быть помещен в каталог httpdocs/ или сервер (я думаю, apache) реагирует на что-то и извлекает его в другой каталог?

  3. Должен ли скрипт PHP иметь разрешение R-X (чтение и выполнение), --X (выполнение) или R-- (чтение)? С точки зрения операционной системы, я думаю, apache просто читает эти файлы, это означает, что они должны быть R--, но это будет означать, что если служба PHP «остановлена», клиент получит весь код PHP в своем браузере (?). Я бы предпочел, чтобы это было --X, но поскольку это не двоичный файл и не имеет #!, я думаю, это должно быть --R?

  4. Если общедоступный сценарий PHP можно поместить в другой каталог (например, /php вместо /httpdocs), что /php (и сценарий) должны иметь для разрешения ?. Я предполагаю, что сервер должен знать об этом каталоге /php (или есть обычные значения по умолчанию?)

  5. Включенный PHP-скрипт (../inc/db_login.php, содержащий пароль SQL) не должен быть ниже /httpdocs Я полагаю. Это означает, что мой register.php включает файл, который не входит в поддерево /httpdocs. Это работает? Сервер должен знать?

Я понимаю, что вам, возможно, нужно знать конфигурацию сервера. Просто примите значение по умолчанию в своем ответе (и вы можете сказать, где оно изменилось, если оно есть).

Ответы [ 5 ]

51 голосов
/ 19 января 2010

Каталоги должны иметь разрешения на выполнение, чтобы их можно было использовать. Обычно это 0755. PHP-скрипты, запускаемые через mod_php, не выполняются, а читаются; 0644 будет достаточно для этого. Каталоги, которые должны быть записаны, чтобы они принадлежали пользователю, от имени которого работает веб-сервер. Могут быть дополнительные проблемы с разрешениями, например, SELinux, но вышеизложенное поможет вам пройти через основы.

Документы, к которым не должны обращаться другие пользователи или внешние клиенты, должны быть 0600, принадлежать пользователю веб-сервера и находиться за пределами DocumentRoot. Обратите внимание, что запуск mod_php в безопасном режиме предотвратит включение скриптами чего-либо вне DocumentRoot; грустный недостаток.

12 голосов
/ 25 апреля 2016

Установите для php-файлов значение 640

Для максимальная защита вы должны установить минимальные разрешения, которые равны 640 .

  • Владелец 6 будет тем, кто загружает файлы.
  • Группа 4 будеттот, который обслуживает файл.Сделайте apache участником группы.
  • nobody 0 означает, что другие пользователи не могут читать этот файл.Это важно, поскольку в php-скриптах иногда есть пароли и другие конфиденциальные данные.

Никогда не разрешайте всем читать php-скрипты.

Полезные команды:

chmod 640 file.php
chown user:group file.php
usermod -a -G group apache

Что делают эти команды:

  1. Изменение владельца файла file.php, чтобы пользователь мог читать и писать, читать группы.
  2. Изменитьвладение файлом file.php для выбранного имени пользователя и имени группы.
  3. Добавьте apache в группу, чтобы apache мог обслуживать файл.В противном случае 640 не будет работать.
1 голос
/ 19 января 2010

1) Файлы с расширением .php передаются компилятору PHP через Apache. Если для этого не настроена правильная конфигурация, файлы PHP обрабатываются сервером как текстовые файлы. Строка конфигурации Apache "AddHandler php5-script php" в файле httpd.conf - это способ установки PHP5.

2) register.php должен быть доступен по адресу http://www.example.com/php/register.php,, поскольку его ищет java-приложение, поэтому в папке Apache htdocs должна быть папка "php" с файлом register.php. в нем.

3) PHP-файлы должны иметь доступ на чтение от пользователя, который запускает службу Apache. Использование PHP в качестве модуля Apache не имеет никакой «службы», о которой можно говорить отдельно для PHP. Вместо этого служба Apache, когда она получает запрос на файл PHP, выполняет вызов оболочки для двоичного файла PHP, чтобы проанализировать файл и передать службе Apache результат, который он передает клиенту. Только если вы используете PHP из командной строки (настройка CLI), сценарии должны иметь разрешение на выполнение и начинаться со строки #!/path/to/php-bin.

4) Запрашиваемый файл (register.php) должен быть в htdocs для обслуживания Apache. Если PHP работает с отключенным «безопасным режимом», то register.php может включать файл, находящийся вне папки htdocs.

5) Путь "../inc/db_login.php" относится к сценарию PHP, который был первоначально извлечен (register.php), поэтому, поскольку register.php находится в htdocs/php/register.php, это поместит db_login.php в htdocs/inc/db_login.php ,

0 голосов
/ 20 января 2010

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

Хорошей практикой является наличие хотя бы одного каталога вне видимых с веб-сервера для хранения включаемых файлов, но путь включения PHP должен по-прежнему включать '.'.

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

/ var / www / htdocs - как корень документа / usr / local / php - для включаемых файлов

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

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

Обычно я настраиваю мои каталоги как drwxrwSr-x, принадлежащий члену группы webdev с владельцем группы в качестве команды webdev (идентификатор пользователя httpd не входит в группу webdev), поэтому файлы имеют вид -rw- rw-r-- Так что любой пользователь в группе webdex может изменять файлы, а пользователь httpd может только читать файлы.

1) означает ли расширение файла (.php) что-то для сервера:

Да - читайте руководство по установке PHP.

С

0 голосов
/ 19 января 2010

Я кодировал функцию для решения проблем с разрешениями в PHP / SuPHP и аналогичных:

function realChmod($path, $chmod = null)
{
    if (file_exists($path) === true)
    {
        if (is_null($chmod) === true)
        {
            $chmod = (is_file($path) === true) ? 644 : 755;

            if (in_array(get_current_user(), array('apache', 'httpd', 'nobody', 'system', 'webdaemon', 'www', 'www-data')) === true)
            {
                $chmod += 22;
            }
        }

        return chmod($path, octdec(intval($chmod)));
    }

    return false;
}

Может быть, это полезно для вас.

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