2010-01-19 3 views
21

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

Веб-сайт содержит документы 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. Это работает? Должен ли сервер знать?

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

ответ

46

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

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

+0

Спасибо за ваш ответ. Я поставлю register.php в httpdocs/php. Теперь я попытался создать/inc и включить ../../inc/db_login.php, но создание/inc было отклонено ... Должен ли db_login.php быть помещен в cgi-bin тогда ?. И если apache находится в безопасном режиме, тогда db_login должен находиться в дереве httpdocs ... разве это не риск для безопасности? –

+0

Ничего, кроме скриптов CGI, не должно быть в 'cgi-bin'. Да, наличие файлов конфигурации под DocumentRoot является потенциальным риском для безопасности; PHP может решить эту проблему, установив опцию config, которая указывает дополнительный каталог, который может быть явно включен. Но это не так. –

+0

Но если оба register.php и db_login.php находятся под корнем html doc, а их разрешения одинаковы, то какой коэффициент усиления (разумный уровень безопасности) должен иметь их в двух разных файлах. Я полагаю, что идея заключалась в том, чтобы иметь «большую безопасность» в отношении паролей, включенных в db_login ...? Разве это не риск того, что код попадет к клиенту, если PHP не удастся? Еще раз большое спасибо за ваше время./C –

1

Я закодировал функцию для решения проблем с разрешениями в обоих 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; 
} 

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

+0

Вы должны использовать восьмеричные литералы вместо того, чтобы иметь дело с этим octdec() cruft и использовать '| =' вместо '+ ='. –

+1

Вы используете PHP-скрипт для исправления разрешений на PHP-скрипт? Если разрешения сервера не работают и не позволяют запускать скрипты PHP, этот скрипт также не будет запущен. Хотя если вы вручную исправите разрешение этого сценария, вы можете использовать его для пакетного восстановления остальных. Однако можно просто использовать 'chmod -R' из командной строки. – MidnightLightning

+0

@MidnightLightning: по-прежнему можно запускать скрипты PHP через CLI, даже если он не работает должным образом на веб-сервере, если у вас есть доступ к оболочке, конечно. Кроме того, 'chmod -R' может быть опасным, лучше использовать правильно созданный' find' вместо этого. –

1

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

2) register.php должен быть доступен по адресу http://www.example.com/php/register.php, так как приложение java ищет его, поэтому в папке htdocs Apache в нем должна быть папка «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

Пункт 3: Установки CLI и CGI требуют разрешения на выполнение. –

0

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

Рекомендуется иметь по крайней мере одну директорию за пределами видимых с веб-сервера, чтобы содержать включенные файлы, но путь включения PHP должен содержать «.».

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

/вар/WWW/HTDOCS - как документ root /usr/local/php - для включения файлов

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

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

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

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

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

C.

9

Установить PHP файлы в 640

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

  • владелец 6 бы один загрузки файлов.
  • Группа будет обслуживать файл. Сделайте 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 не будет работать.