Ketidakamanan pengaturan PHP yang umum?

10

Saya bekerja dengan administrasi sistem di sebuah universitas dan hanya menemukan sesuatu yang mungkin biasa, tetapi cukup mengejutkan bagi saya.

Semua direktori public_html dan area web disimpan di afs, dengan izin baca untuk server web. Karena pengguna diizinkan memiliki skrip php di public_html mereka, ini berarti mereka dapat mengakses file satu sama lain dari dalam php (dan file web utama!).

Ini tidak hanya membuat perlindungan kata sandi .htaccess sama sekali tidak berguna, itu juga memungkinkan pengguna untuk membaca file sumber php yang berisi kata sandi database mysql dan informasi sensitif serupa. Atau jika mereka menemukan bahwa orang lain memiliki direktori di mana server web memiliki akses tulis (misalnya untuk log pribadi atau untuk menyimpan data formulir yang dikirimkan), mereka dapat menyimpan file di akun tersebut.

Contoh sederhana:

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

Apakah ini masalah umum? Dan bagaimana Anda biasanya menyelesaikannya?

MEMPERBARUI:

Terima kasih atas masukannya. Sayangnya, sepertinya tidak ada jawaban sederhana. Dalam lingkungan bersama yang besar seperti ini, pengguna mungkin tidak boleh diberikan pilihan sebanyak ini. Pendekatan terbaik yang dapat saya pikirkan adalah dengan menetapkan "open_basedir" dalam konfigurasi utama untuk semua direktori "public_html", jalankan suphp dan hanya izinkan php bersih (tanpa skrip cgi, menjalankan perintah eksternal dengan backticks dll).

Mengubah kebijakan seperti ini akan menghancurkan banyak hal, dan sangat mungkin membuat pengguna mengambil garpu rumput mereka dan mengejar kami ... Saya akan membahasnya dengan rekan-rekan saya dan memperbarui di sini jika kami membuat keputusan tentang bagaimana mengubah pengaturan.

apache-2.2 security php

— Pontus
sumber

Ini pertanyaan yang menarik. Saya yakin pada penyedia utama hosting bersama (mis. DreamHost), ini tidak mungkin. Tetapi saya akan tertarik pada bagaimana mereka melindungi dari ini. suphp, seperti disebutkan cstamas, sepertinya solusi yang bagus, tetapi apakah ini yang digunakan oleh sebagian besar penyedia hosting?

— Lèse majesté

1

Saya telah menggunakan open_basedirsolusi di bawah ini pada sistem shared hosting produksi, tapi kami membagi semua orang menjadi vhost mereka sendiri - Tidak yakin apakah itu berfungsi untuk direktori tunggal ...

— voretaq7

8

Satu dapat menggunakan suphp yang menjalankan skrip php dengan uid dari pemiliknya.

http://www.suphp.org

— cstamas
sumber

Ini mungkin tidak akan menyelesaikan masalah di atas (setidaknya di lingkungan hosting bersama file .htpasswd biasanya dimiliki oleh pengguna yang memiliki situs dan grup (apache) atau dunia (karena pengguna tidak tahu / peduli dengan keamanan) dapat dibaca, bahkan dengan suphp mereka bisa membaca file-file itu)

— voretaq7

@ voretaq7: Beberapa batasan lain dapat diterapkan. Sejauh yang saya ingat Anda bahkan dapat menolak akses ke file yang bukan milik Anda. Jadi ini mengesampingkan serangan di atas.

— cstamas

Saya tahu Anda dapat membatasi izin pada file ("Tidak dapat ditulis oleh grup / orang lain / siapa pun"), tetapi saya tidak tahu cara memblokir pemblokiran di luar izin FS. Mereka punya check_vhost_docroot, tetapi AFAIK yang hanya berlaku untuk skrip dieksekusi (? Saya bisa salah tentang itu)

— voretaq7

1

Saya tidak yakin apakah suphp adalah solusi yang baik di lingkungan seperti ini. Seorang pengguna dapat memiliki segala macam izin yang tidak dimiliki oleh pengguna www. Penyerang yang menemukan jalan masuk melalui php dapat menemukan kunci ssh atau keytab, atau mengubah skrip login pengguna untuk membuat backdoors. Dan pengaturan "vhosts" tidak terlalu membantu karena direktori public_html tersedia melalui "/ ~ nama pengguna" pada host virtual utama. Saya pikir mungkin skrip di public_html harus dinonaktifkan sepenuhnya.

— Pontus

4

Saran saya adalah membatasi akses PHP ke file (melalui open_basedir& arahan serupa, berdasarkan per-vhost): Anda ingin pengguna dapat membuka / membaca / menulis file di webroot mereka, dan mungkin satu tingkat di atasnya (untuk awal space), tetapi bukan direktori tempat mereka menyimpan misalnya htpasswdfile.

Struktur direktori seperti:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Akan memenuhi persyaratan ini: open_basedirdapat diarahkan dengan /Client/siteaman, dan htpasswdfile disimpan dalam /Client/auth(dengan .htaccessfile atau httpd.confdimodifikasi untuk menunjuk pada lokasi yang sesuai sebagai gantinya).
Ini mencegah klien Anda membuka file orang lain, DAN sebagai manfaat, pengguna jahat tidak dapat membaca hal-hal itu /Client/auth(atau apa pun di sistem Anda, seperti /etc/passwd:-)

Lihat http://php.net/manual/en/ini.core.php untuk detail lebih lanjut tentang implementasi open_basedir & per-vhost.

— voretaq7
sumber

1

suphpseperti dicatat oleh cstamas juga merupakan ide yang sangat bagus di lingkungan shared hosting - Ada sedikit overhead yang mengaturnya, tapi saya akan mengatakan bahwa keuntungan keamanan benar-benar layak. Singkat sandboxing semua situs PHP Anda dalam sesuatu seperti FreeBSD Jail atau mesin virtual khusus yang merupakan salah satu yang menang keamanan terbesar.

— voretaq7

"open_basedir" tampaknya menjadi cara sederhana untuk memisahkan file web utama dari yang pengguna, asalkan "public_html" dilayani melalui virtual host itu sendiri. Tetapi itu tidak melindungi pengguna dari satu sama lain, karena mereka tidak memiliki host virtual sendiri. Baik?

— Pontus

Saya belum mencoba pengaturan open_basedirdi dalam direktif <Directory>, tapi saya pikir itu harus diijinkan ("coba dan lihat" - yang terburuk tidak dapat dilakukan :)

— voretaq7

1

Sejauh ini sepertinya open_basedir adalah apa yang digunakan oleh sebagian besar web host komersial (biasanya pelanggan memiliki domain berbayar mereka sendiri atau menerima subdomain gratis), tetapi untuk homepage berbasis direktori seperti di lembaga akademik, suphp tampaknya menjadi jawaban terbaik.

— Lèse majesté

1

Tidak, ini bukan masalah umum karena kebanyakan host bersama akan mendefinisikan konfigurasi open_basedir dalam file htaccess di direktori public_html setiap pengguna (atau di vhost jika setiap pengguna memiliki vhost sendiri).

misalnya dari file .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

Tetapi pastikan Anda menetapkan izin yang tepat pada file .htaccess untuk mencegah pengguna mengubah open_basedir (jika mereka mencoba menimpanya di subdir / .htaccess, itu tidak akan berfungsi - tetapi Anda mungkin harus menguji ini untuk memastikan) .

HTH

C.

— symcbean
sumber

2

Ini mungkin membantu untuk menawarkan beberapa perlindungan awal dari akun baru. Tetapi fakta bahwa pengguna tidak dapat mengeditnya dapat membuatnya tergoda untuk menghapus file .htaccess (yang dapat mereka lakukan karena hanya memerlukan akses tulis ke direktori public_html) dan buat sendiri. Menambahkan "<Directory>" -block di konfigurasi utama untuk setiap pengguna akan berfungsi, tetapi di sini mereka masih diperbolehkan untuk memilih kembali perintah eksternal dari php, yang berarti open_basedir mudah dielakkan.

— Pontus

@Pontus: poin bagus tentang menghapus file (Saya tidak yakin apakah afs mendukung atribut file yang tidak dapat diubah). Saya akan memberi +1 jika Anda mengatakan bahwa menjalankan server web di chroot jail akan melindungi dari semua jenis kerentanan eksekusi program.

— symcbean

1

AFS mengabaikan izin pengguna unix sederhana. suPHP mengeksekusi setuid sebelum menjalankan program php, tetapi itu tidak memberikan proses token kerberos yang diperlukan untuk mengakses AFS dan dibatasi untuk izinnya. suPHP harus dimodifikasi dengan cara tertentu untuk memperoleh token tersebut sebelum dapat muncul dengan sendirinya ke sistem AFS sebagai pengguna itu. Sejauh yang saya tahu, itu belum dilakukan. (Sebenarnya, saya menemukan pertanyaan ini ketika mencari untuk melihat apakah ada orang lain yang melakukannya.)

— Charles B
sumber