Typowa niepewność konfiguracji PHP?

10

Pracuję z administracją systemów na uniwersytecie i natknąłem się na coś, co prawdopodobnie jest powszechne, ale było dla mnie dość szokiem.

Wszystkie katalogi public_html i obszary sieciowe są przechowywane w systemie plików afs, z uprawnieniami do odczytu dla serwerów sieciowych. Ponieważ użytkownicy mogą mieć skrypty php w swoim pliku public_html, oznacza to, że mogą uzyskiwać dostęp do swoich plików z poziomu php (i głównych plików internetowych!).

To sprawia, że ​​ochrona hasłem .htaccess jest całkowicie bezużyteczna, ale pozwala również użytkownikom czytać pliki źródłowe php zawierające hasła do bazy danych mysql i podobne poufne informacje. Lub jeśli stwierdzą, że inne osoby mają katalogi, w których serwery internetowe mają dostęp do zapisu (np. Do dzienników osobistych lub w celu zapisania przesłanych danych formularza), mogą przechowywać pliki na tych kontach.

Prosty przykład:

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

Czy to powszechny problem? Jak zazwyczaj to rozwiązujesz?

AKTUALIZACJA:

Dzięki za wkład. Niestety wydaje się, że nie ma prostej odpowiedzi. W dużym wspólnym środowisku, takim jak to, użytkownicy prawdopodobnie nie powinni mieć tak dużego wyboru. Najlepszym podejściem, jakie mogę wymyślić, jest ustawienie „open_basedir” w głównej konfiguracji dla wszystkich katalogów „public_html”, uruchomienie suphp i zezwolenie tylko na czyste php (bez skryptów cgi, uruchamianie zewnętrznych poleceń z backtickami itp.).

Zmiana zasad w ten sposób złamałaby wiele rzeczy i całkiem możliwe, że użytkownicy złapią widły i nas ścigają ... Omówię to z kolegami i zaktualizuję tutaj, jeśli podejmiemy decyzję o zmianie konfiguracji.

apache-2.2 security php Pontus
źródło
To interesujące pytanie. Jestem pewien, że w przypadku głównych dostawców hostingu współdzielonego (np. DreamHost) nie jest to możliwe. Byłbym jednak zainteresowany tym, jak się przed tym chronią. suphp, jak wspomniano cstamas, wygląda na dobre rozwiązanie, ale czy tego używa większość dostawców hostingu?
Lèse majesté
1
Użyłem open_basedirponiższego rozwiązania na produkcyjnych współdzielonych systemach hostingu, ale podzieliliśmy wszystkich na ich własnych vhostów - Nie jestem pewien, czy to działa dla pojedynczych katalogów ...
voretaq7

Odpowiedzi:

8

Można użyć suphp, który uruchamia skrypt php z identyfikatorem użytkownika jego właściciela.

http://www.suphp.org

cstamas
źródło
Prawdopodobnie nie rozwiąże to powyższego problemu (przynajmniej we współdzielonym środowisku hostingowym pliki .htpasswd są zazwyczaj własnością użytkownika, który jest właścicielem witryny i grupy (apache) lub świata (ponieważ użytkownicy nie wiedzą / dbają o bezpieczeństwo), czytelny, więc nawet z suphp będą w stanie odczytać te pliki)
voretaq7
@ voretaq7: Można zastosować kilka innych ograniczeń. O ile pamiętam, możesz nawet odmówić dostępu do plików, których nie jesteś właścicielem. To wyklucza powyższy atak.
cstamas
Wiem, że możesz ograniczyć uprawnienia do plików („Nie można zapisywać przez grupę / inne / nikogo”), ale nie znam sposobu blokowania odczytów poza uprawnieniami FS. Mają check_vhost_docroot, ale AFAIK dotyczy tylko wykonywanego skryptu (? Mogę się mylić)
voretaq7
1
Nie jestem pewien, czy suphp jest dobrym rozwiązaniem w takim środowisku. Użytkownik może mieć wszelkiego rodzaju uprawnienia, których nie ma użytkownik www. Osoba atakująca, która znalazła drogę przez php, może znaleźć klucze ssh lub keytabs lub zmienić skrypty logowania użytkowników, aby utworzyć backdoory. A ustawienia „vhosts” nie są tak pomocne, ponieważ katalogi public_html są dostępne poprzez „/ ~ nazwa użytkownika” na głównym hoście wirtualnym. Myślę, że może skrypty w public_html powinny być całkowicie wyłączone.
Pontus
4

Moją sugestią byłoby ograniczenie dostępu PHP do plików (poprzez open_basediri podobne dyrektywy, na zasadzie na vhosta): Chcesz, aby użytkownicy mogli otwierać / odczytywać / zapisywać pliki pod ich katalogiem głównym i być może o jeden poziom wyżej (do zera spacja), ale nie katalog, w którym byłyby przechowywane np htpasswd. pliki.

Struktura katalogów takich jak:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Spełniałby to wymaganie: open_basedirmoże być /Client/sitebezpiecznie wskazany , a htpasswdpliki przechowywane w /Client/auth(z .htaccessplikami lub httpd.confzmodyfikowane tak, aby wskazywały w odpowiednim miejscu).
Zapobiega to otwieraniu plików przez innych klientów ORAZ jako korzyść szkodliwi użytkownicy nie mogą odczytać zawartości /Client/auth(ani niczego innego w systemie, np . /etc/passwd:-)

Zobacz http://php.net/manual/en/ini.core.php, aby uzyskać więcej informacji na temat implementacji open_basedir i per-vhost.

voretaq7
źródło
1
suphpjak zauważył cstamas, jest to również dobry pomysł w środowisku hostingu współdzielonego - konfiguracja jest trochę obciążona, ale powiedziałbym, że zwiększenie bezpieczeństwa jest całkowicie tego warte. Brak piaskownicy wszystkich stron PHP w więzieniu FreeBSD lub dedykowanej maszynie wirtualnej, która jest jedną z największych wygranych w dziedzinie bezpieczeństwa.
voretaq7
„open_basedir” wydaje się być prostym sposobem na oddzielenie głównych plików internetowych od plików użytkownika, pod warunkiem, że „public_html” jest obsługiwany przez jego własny wirtualny host. Ale to nie chroni użytkowników przed sobą, ponieważ nie mają własnych wirtualnych hostów. Dobrze?
Pontus
Nie próbowałem ustawiać open_basedirwewnątrz dyrektywy <Directory>, ale myślę, że powinna być dopuszczalna („spróbuj i zobacz” - najgorsze, co może zrobić, to nie działa :)
voretaq7
1
Jak dotąd wygląda na to, że open_basedir jest tym, z czego korzysta większość komercyjnych hostów internetowych (zwykle subskrybenci mają swoje własne płatne domeny lub otrzymują bezpłatną subdomenę), ale w przypadku stron internetowych opartych na katalogach, takich jak instytucje akademickie, suphp wydaje się najlepszą odpowiedzią.
Lèse majesté
1

Nie, nie jest to częsty problem, ponieważ większość współdzielonych hostów definiowałaby konfigurację open_basedir w pliku htaccess w katalogu public_html każdego użytkownika (lub w vhost, jeśli każdy użytkownik ma swój własny vhost).

np. pliku .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

Ale upewnij się, że ustawiłeś odpowiednie uprawnienia do pliku .htaccess, aby uniemożliwić użytkownikowi zmianę open_basedir (jeśli spróbują zastąpić go w subdir / .htaccess, nie powinno to działać - ale prawdopodobnie powinieneś to przetestować, aby się upewnić) .

HTH

DO.

symcbean
źródło
2
Może to pomóc w zapewnieniu początkowej ochrony nowych kont. Ale fakt, że użytkownik nie może go edytować, może sprawić, że kusi go usunięcie pliku .htaccess (co mogą zrobić, ponieważ wymaga tylko dostępu do zapisu do katalogu public_html) i utworzenia własnego. Dodanie „<Directory>” -block w głównej konfiguracji dla każdego użytkownika będzie działało, ale tutaj nadal mogą cofać polecenia zewnętrzne z php, co oznacza, że ​​łatwo można obejść open_basedir.
Pontus
@Pontus: dobra uwaga na temat usuwania pliku (nie jestem pewien, czy afs obsługuje atrybut niezmiennego pliku). Dałbym +1, gdybyś powiedział, że uruchomienie serwera w więzieniu chroot chroniłoby przed wszelkiego rodzaju lukami w wykonywaniu programu.
symcbean
1

AFS ignoruje proste uprawnienia użytkownika unix. suPHP wykonuje setuid przed uruchomieniem programu php, ale to nie daje procesowi tokenów Kerberos potrzebnych do uzyskania dostępu do AFS i ograniczenia się do jego uprawnień. suPHP musiałby zostać zmodyfikowany w jakiś sposób, aby uzyskać te tokeny, zanim mógłby się zaprezentować w systemie AFS jako ten użytkownik. O ile mi wiadomo, nie zostało to zrobione. (W rzeczywistości znalazłem to pytanie, gdy chciałem sprawdzić, czy zrobił to ktoś inny.)

Charles B.
źródło