Общая небезопасная настройка PHP?

Я работаю с системным администратором в университете и просто наткнулся на что-то, что, вероятно, распространено, но для меня было шоком.

Все каталоги public_html и веб-области хранятся в afs с разрешениями на чтение для веб-серверов. Поскольку пользователям разрешено иметь php-скрипты в своем public_html, это означает, что они могут получать доступ к файлам друг друга изнутри php (и основных веб-файлов!).

Это не только делает бесполезной защиту паролем.htaccess, но также позволяет пользователям читать исходные файлы php, содержащие пароли базы данных mysql и аналогичную конфиденциальную информацию. Или, если они обнаружат, что другие люди имеют каталоги, к которым веб-серверы имеют доступ для записи (например, для личных журналов или для сохранения отправленных данных формы), они могут хранить файлы в этих учетных записях.

Простой пример:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

Это общая проблема? И как вы обычно это решаете?

ОБНОВИТЬ:

Спасибо за вклад. К сожалению, кажется, нет простого ответа. В большой общей среде, такой как эта, пользователям, вероятно, не следует предоставлять такой большой выбор. Лучший подход, который я могу придумать, - это установить "open_basedir" в основной конфигурации для всех каталогов "public_html", запустить suphp и разрешить только чистый php (без сценариев cgi, выполнение внешних команд с обратными галочками и т. Д.).

Такое изменение политики может привести к поломке многих вещей и, вполне возможно, к тому, что пользователи схватят свои вилы и будут преследовать нас... Я буду обсуждать это с моими коллегами и обновлять здесь, если мы примем решение о том, как изменить установку.

Источник

4 ответа

Решение

Можно использовать suphp, который запускает скрипт php с идентификатором своего владельца.

http://www.suphp.org/

Источник

Мое предложение будет ограничивать доступ PHP к файлам (через open_basedir & аналогичные директивы, для каждого хоста): вы хотите, чтобы пользователи могли открывать / читать / записывать файлы в своем веб-корне и, возможно, на один уровень выше (для чистого пространства), а не в каталог, где они будут хранить например htpasswd файлы.

Структура каталогов, например:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Будет соответствовать этому требованию: open_basedir может быть указано на /Client/site безопасно и htpasswd файлы хранятся в /Client/auth (с .htaccess файлы или httpd.conf изменено, чтобы указать на соответствующее местоположение вместо этого).
Это препятствует тому, чтобы ваши клиенты открывали чужие файлы, и в качестве преимущества злоумышленники не могут читать материалы в /Client/auth (или что-то еще в вашей системе, например, /etc/passwd:-)

См. http://php.net/manual/en/ini.core.php для получения дополнительной информации о реализации open_basedir & per-vhost.

Источник

AFS игнорирует простые пользовательские разрешения Unix. suPHP выполняет setuid перед запуском php-программы, но это не дает процессу токенов kerberos, необходимых для доступа к AFS, и ограничивается его разрешениями. Для получения этих токенов необходимо было бы каким-то образом изменить suPHP, прежде чем он сможет представить себя в системе AFS в качестве этого пользователя. Насколько я знаю, это не было сделано. (На самом деле, я нашел этот вопрос, когда посмотрел, сделал ли это кто-нибудь еще.)

Источник

Нет, это не распространенная проблема, поскольку большинство общих хостов определяют конфигурацию open_basedir в файле htaccess в каталоге public_html каждого пользователя (или в vhost, если у каждого пользователя есть собственный vhost).

например, файла.htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Но убедитесь, что вы установили правильные разрешения для файла.htaccess, чтобы предотвратить изменение пользователем open_basedir (если они пытаются переопределить его в subdir /.htaccess, это не должно работать - но вам, вероятно, следует проверить это, чтобы убедиться),

НТН

C.

Источник
Другие вопросы по тегам