Поширена безпека налаштування 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, запуску зовнішніх команд із задніми таблицями тощо).

Якщо змінити таку політику, можна було б зламати багато речей, і цілком можливо змусити користувачів захопити їхні вини та переслідувати нас ... Я обговорю це з колегами та оновлю тут, якщо ми приймемо рішення про те, як змінити налаштування.

Можна використовувати suphp, який запускає скрипт php з уid його власника.

http://www.suphp.org

Моя пропозиція полягатиме в тому, щоб обмежити доступ PHP до файлів (через open_basedir& подібні директиви, на основі vhost): Ви хочете, щоб користувачі могли відкривати / читати / писати файли під їх веб-корінням, а можливо, на один рівень над ним (для нуля простір), але не каталог, де вони зберігатимуть, наприклад, 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.

Ні, це не є загальною проблемою, оскільки більшість спільних хостів визначають конфігурацію 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, він не повинен працювати - але, мабуть, вам слід перевірити це) .

HTH

C.

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