Yaygın PHP kurulum güvensizliği?

10

Bir üniversitede sistem yönetimi ile çalışıyorum ve muhtemelen yaygın olan ancak benim için oldukça şok edici bir şeyle karşılaştım.

Tüm public_html dizinleri ve web alanları, web sunucuları için okuma izinleriyle afs'de saklanır. Kullanıcıların public_html dosyalarında php komut dosyalarına sahip olmalarına izin verildiğinden, bu birbirlerinin dosyalarına php (ve ana web dosyaları!) İçinden erişebilecekleri anlamına gelir.

Bu sadece herhangi bir .htaccess şifre koruması tamamen işe yaramaz hale getirmekle kalmaz, aynı zamanda kullanıcıların mysql veritabanı şifreleri ve benzer hassas bilgileri içeren php kaynak dosyalarını okumasına izin verir. Veya diğer kişilerin web sunucularının yazma erişimine sahip olduğu dizinleri buldukları takdirde (örneğin, kişisel günlükler veya gönderilen form verilerini kaydetmek için) bu hesaplarda dosya depolayabilirler.

Basit bir örnek:

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

Bu yaygın bir sorun mu? Ve tipik olarak nasıl çözersiniz?

GÜNCELLEME:

Giriş için teşekkürler. Ne yazık ki, basit bir cevap yok gibi görünüyor. Böyle büyük bir paylaşılan ortamda, kullanıcılara muhtemelen bu kadar seçenek verilmemelidir. Aklıma gelen en iyi yaklaşım, tüm "public_html" dizinleri için ana yapılandırmada "open_basedir" ayarlamak, suphp çalıştırmak ve sadece temiz php (cgi komut dosyası yok, ters komutlarla harici komutları çalıştırma) izin vermektir.

Böyle bir politikayı değiştirmek birçok şeyi kırabilir ve büyük olasılıkla kullanıcıların dirgenlerini kapmasını ve bizi kovalamasını sağlar ... Kurulumu nasıl değiştireceğimize karar verirsek, meslektaşlarımla tartışacağım ve burada güncelleyeceğim.

apache-2.2 security php

— Pontus
kaynak

Bu ilginç bir soru. Büyük paylaşılan hosting sağlayıcıları (örneğin DreamHost) eminim, bu mümkün değil. Ama bundan nasıl korudukları ile ilgilenirim. suphp, cstamas'ın belirttiği gibi, iyi bir çözüm gibi görünüyor, ancak çoğu barındırma sağlayıcısının kullandığı şey bu mu?

— Lèse majesté

1

Kullandığım open_basedirüretim sistemlerini barındıran paylaşılan üzerinde çözüm aşağıda ama kendi vhostu herkesi bölünmüş - Emin değilim o ... tek dizinleri için çalışıyorsa

— voretaq7

8

Bir php komut dosyasını sahibinin uid ile çalıştıran suphp kullanabilirsiniz.

http://www.suphp.org

— cstamas
kaynak

Bu muhtemelen yukarıdaki sorunu çözmeyecektir (en azından paylaşılan bir barındırma ortamında .htpasswd dosyaları genellikle sitenin ve grubun (apache) veya dünyaya sahip olan kullanıcının sahip olduğu (kullanıcıların güvenliği bilmediği / umursamadığı), suphp ile bile bu dosyaları okuyabilecekler)

— voretaq7

@ voretaq7: Başka kısıtlamalar da uygulanabilir. Hatırladığım kadarıyla sahip olmadığınız dosyalara erişimi bile reddedebilirsiniz. Yani bu yukarıdaki saldırıyı ortadan kaldırıyor.

— cstamas

Dosyalardaki izinleri sınırlandırabileceğinizi biliyorum ("Grup / diğer / kimse tarafından yazılamaz"), ancak FS izinlerinin ötesinde okumaları engellemenin bir yolunu bilmiyorum. Onlar var check_vhost_docroot, ama sadece çalıştırılan komut dosyası için geçerli AFAIK (? Bu konuda yanlış olabilir)

— voretaq7

1

Suphp'in böyle bir ortamda iyi bir çözüm olup olmadığından emin değilim. Bir kullanıcı www-kullanıcısının sahip olmadığı her türlü izne sahip olabilir. Php yoluyla bir yol buldu bir saldırgan ssh anahtarları veya keytabs bulabilir veya bir arka planda oluşturmak için bir kullanıcının giriş komut dosyaları değiştirebilirsiniz. Genel sanal ana bilgisayardaki "/ ~ kullanıcı adı" üzerinden public_html dizinleri bulunduğundan "vhosts" ayarları o kadar yararlı değildir. Ben public_html belki script tamamen devre dışı bırakılması gerektiğini düşünüyorum.

— Pontus

4

Benim önerim PHP'nin dosyalara erişimini sınırlamak olacaktır ( open_basedirve benzer yönergeler aracılığıyla , vhost temelinde): Kullanıcıların webrootları altında dosyaları ve belki de bir seviye üstünde (çizik için) boşluk), ancak örneğin htpasswddosyaları depolayacakları bir dizin değil .

Aşağıdaki gibi bir dizin yapısı:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Bu şartı karşılardı: güvenle open_basedirişaret edilebilir /Client/siteve htpasswddosyalar depolanır /Client/auth( .htaccessdosyalarla veya httpd.confbunun yerine uygun konumu işaret edecek şekilde değiştirilir).
Bu, müşterilerinizin başkalarının dosyalarını açmasını önler VE bir avantaj olarak, kötü niyetli kullanıcılar bu öğeleri /Client/auth(veya sisteminizdeki /etc/passwd:-) gibi başka bir şeyi okuyamaz.

Open_basedir ve hayalet başına uygulama hakkında daha fazla bilgi için http://php.net/manual/en/ini.core.php adresine bakın .

— voretaq7
kaynak

1

suphpcstamas tarafından belirtildiği gibi paylaşılan bir barındırma ortamında gerçekten iyi bir fikir - kurmak biraz yükü var, ama güvenlik kazancı tamamen buna değer olduğunu söyleyebilirim. Tüm PHP sitelerinizi FreeBSD Hapishanesi veya en büyük güvenlik kazançlarından biri olan özel bir sanal makine gibi bir yerde sandbox olarak kullanmakta yetersiz kalıyoruz.

— voretaq7

"open_basedir", kendi web sunucusu üzerinden "public_html" sunulması koşuluyla, ana web dosyalarını kullanıcılardan ayırmanın basit bir yolu gibi görünmektedir. Ancak kendi sanal ana bilgisayarlarına sahip olmadıkları için kullanıcıları birbirlerinden korumaz. Sağ?

— Pontus

open_basedirBir <Directory> yönergesi içinde ayarlama denemedim , ama izin verilebilir gerektiğini düşünüyorum ("denemek ve görmek" - yapabileceği en kötü iş değildir :)

— voretaq7

1

Şimdiye kadar open_basedir çoğu ticari web barındırma (genellikle abonelerin kendi ücretli etki alanlarına sahip veya ücretsiz bir alt alan adı alır) kullandıkları gibi görünüyor, ancak akademik bir kurumda olduğu gibi dizin tabanlı ana sayfalar için suphp en iyi yanıt gibi görünüyor.

— Lèse majesté

1

Hayır, bu ortak bir sorun değildir, çünkü çoğu paylaşılan ana bilgisayar her kullanıcının public_html dizinindeki htaccess dosyasında (veya her kullanıcının kendi hayaletine sahip olması durumunda vhost'ta) bir open_basedir yapılandırması tanımlayacaktır.

örneğin .htaccess dosyası:

# 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

Ancak, kullanıcının open_basedir'i değiştirmesini önlemek için .htaccess dosyasında doğru izinleri ayarladığınızdan emin olun (alt dizinde / .htaccess'te geçersiz kılmaya çalışırlarsa, işe yaramaz - ancak muhtemelen emin olmak için bunu test etmelisiniz) .

HTH

C.

— symcbean
kaynak

2

Bu, yeni hesapların başlangıçta korunmasını sağlamaya yardımcı olabilir. Ancak bir kullanıcının dosyayı düzenleyememesi, .htaccess dosyasını (yalnızca public_html dizinine yazma erişimi gerektirdiği için yapabilecekleri) kaldırmayı ve kendi oluşturmayı cazip hale getirebilir. Her kullanıcı için ana yapılandırmada bir "<Directory>" bloğu eklemek işe yarayacaktır, ancak burada php'den harici komutları geri almasına izin verilir, bu da open_basedir'in kolayca atlatılabileceği anlamına gelir.

— Pontus

@Pontus: dosyayı silme konusunda iyi bir nokta (afs'ın değişmez dosya özniteliğini destekleyip desteklemediğinden emin değilim). Web sunucusunu chroot hapishanesinde çalıştırmanın her türlü program yürütme güvenlik açığına karşı koruyacağını söyleseydiniz +1 verirdim.

— symcbean

1

AFS, basit unix kullanıcı izinlerini yok sayar. suPHP, php programını çalıştırmadan önce bir setuid yürütür, ancak bu işleme AFS'ye erişmek ve izinleriyle sınırlandırılması için gereken kerberos belirteçlerini vermez. suPHP, kendisini bu kullanıcı olarak AFS sistemine sunmadan önce bu tokenleri elde etmek için bir şekilde değiştirilmelidir. Bildiğim kadarıyla bu yapılmadı. (Aslında, başka birinin bunu yapıp yapmadığını görmek için bu soruyu buldum.)

— Charles B
kaynak