Mengamankan server web PHP


31

Aplikasi PHP memiliki reputasi untuk masalah keamanan yang lebih tinggi dari rata-rata. Teknik konfigurasi apa yang Anda gunakan untuk memastikan aplikasi seaman mungkin?

Saya mencari ide-ide seperti:

Saya biasanya menggunakan Linux, tetapi jangan ragu untuk menyarankan solusi Windows juga.

Jawaban:


15
  1. Gunakan arahan open_basedir untuk membatasi skrip PHP Anda ke direktori home dan akhirnya direktori aplikasi tambahan. Ini sangat efisien dengan sendirinya.

  2. Gunakan php yang diperkeras karena tidak ada biaya dan itu bisa membantu.

  3. Gunakan suPHP untuk mengeksekusi skrip PHP sebagai pemilik file (satu pengguna per situs web) dan menghindari penggunaan file dengan izin buruk seperti 777 ... suPHP juga dapat memungkinkan Anda untuk menggunakan php.ini per situs web sehingga satu situs bodoh persyaratan tidak menghancurkan segalanya.

  4. Mod_security merupakan nilai tambah yang besar tetapi harus digunakan dan dikonfigurasi dengan baik.


Beberapa situs yang buruk sebenarnya membutuhkan register_globals dan fopen sehingga itu sebabnya Anda menggunakan php.ini per situs dengan suPHP. Satu situs hanya dapat kamikaze dan yang lainnya (hampir) sangat aman.
Antoine Benkemoun

4
Jika mereka menggunakan register_globals dan fopen, itu menunjukkan kualitas sangat buruk Anda mungkin ingin mempertimbangkan kembali menggunakan mereka :)
David Pashley

Jika mereka membayar € 150 / bulan, Anda tidak mempertimbangkan kembali.
Antoine Benkemoun

3

Dalam pengalaman saya, sebagian besar kerentanan pada situs web berbasis PHP adalah hasil dari desain (situs) yang buruk, bukan kelemahan dalam PHP itu sendiri.

Beberapa kiat cepat:

  • Menyaring input secara universal , keluar dari output. Klarifikasi: filter tidak berarti melarikan diri, itu berarti "jika saya menemukan sesuatu yang mencurigakan dalam input pengguna ini, menyebabkan pengiriman gagal dan memberitahu pengguna untuk memformat ulang."
  • Daripada menggunakan escapeshellcmd (), cukup jangan izinkan input pengguna dieksekusi di shell . Itu berbahaya dan mungkin tidak pernah benar-benar diperlukan.
  • Jangan panggil fungsi seperti phpinfo () di situs produksi (atau jika ya, lihat di bawah *).
  • Saat merancang aplikasi web, selalu pertimbangkan "apakah ini vektor serangan yang mungkin?" Katakanlah, injeksi SQL. Jika jawabannya "ya," tancapkan segera - jangan katakan "ok, saya akan menambahkan itu nanti dalam pengembangan sebagai fitur." Keamanan tidak pernah menjadi fitur.
  • Jangan pernah tampilkan kesalahan mentah kepada pengguna; ini berarti mengatur display_errors php.ini = Off, log_errors = On. Jebak kesalahan run-time dan hasilkan sesuatu yang cantik. Ambil paus Twitter sebagai contoh: itu tidak akan memberikan informasi tingkat debug pengguna, ia hanya mengatakan "woops, ada yang rusak, tolong segarkan".

* Anda juga dapat mengintip posting singkat yang saya tulis berjudul "Mengamankan phpinfo (), semacam" dan pastikan untuk membaca komentar http://egovsergo.com/2009/04/03/protecting-your-phpinfo/ Itu adalah ide cepat saya harus (agak) melindungi phpinfo () jika saya entah bagaimana menghapusnya di situs produksi.

Dalam cara yang lebih umum, beberapa pengembang menulis pembungkus untuk fungsi sensitif yang memeriksa apakah bendera "situs produksi" diatur atau tidak, dan menonaktifkan fungsi sensitif dalam produksi.


Pertanyaan saya lebih tentang bagaimana melindungi server Anda terhadap PHP yang ditulis dengan buruk. :) Saya tidak bermaksud bahwa PHP itu sendiri tidak aman, lebih dari itu menarik pengembang kurang berpengalaman dan perpustakaan standar mengharuskan mereka untuk mengingat untuk melindungi setiap panggilan, daripada perpustakaan yang melindungi semua pengguna. Memberi +1 sebagai jawaban yang sangat berguna.
David Pashley

Saya mendapat kesan itu dan menjawab sesuai dengan itu :) Terima kasih atas komentarnya! Saya tidak bisa membahas semuanya di sini, tentu saja, tetapi itu adalah beberapa lubang besar. Jika Anda memiliki pertanyaan yang lebih spesifik, Anda pasti dapat mengajukannya di Stack Overflow dan saya dan semua orang akan berkontribusi. (Dan untuk apa nilainya, saya seorang ZCE).
msanford

3

Parameter lain yang harus diubah untuk mengeraskan PHP:

safe_mode = Off
register_globals = Off
expose_php = Off
allow_url_fopen = Off
allow_url_include = Off
log_errors = On
error_log = /var/log/phperror.log
display_errors = Off
enable_dl = Off
disable_functions="popen,exec,system,passthru,proc_open,shell_exec,show_source,phpinfo"

Simpan semua kesalahan PHP di file /var/log/phperror.log :

touch /var/log/phperror.log
chmod 666 /var/log/phperror.log

1

Saya telah menambahkan repositori dotdeb ke /etc/apt/sources.lst saya

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Karena mereka menambal php / apache / mysql lebih sering daripada Debian.


1

Pertimbangkan pengaturan open_basedirberdasarkan "per situs". open_basediradalah pengaturan php.ini yang akan mencegah skrip Anda mengakses file di luar daftar putih yang ditentukan. Jika server Anda meng-host beberapa situs, itu akan mencegah satu situs dari membaca pengaturan database dari situs lain. Ini juga akan mencegah skrip php dari mengakses / memodifikasi file sistem inti. Open basedir mudah diatur, cukup tambahkan baris " php_admin_value open_basedir /my/list/of/folders:/as/a/colon/seperated/list" ke setiap vhost Apache.

Juga pertimbangkan mematikan mesin skrip PHP untuk semua situs / folder yang tidak boleh berisi skrip PHP (misalnya folder gambar yang diunggah). Sekali lagi, ini sederhana, tambahkan "php_admin_value engine off" ke Apache VirtualHosts yang tidak memerlukan php. Untuk menonaktifkan PHP di direktori, masukkan hal yang sama ke tag Direktori.

Jalankan izin file seketat mungkin, hindari akses tulis ke skrip PHP untuk pengguna Apache, ini mencegah skrip yang berjalan dari memodifikasi sendiri atau skrip lain di situs / server yang sama. Hindari 777 izin jika memungkinkan, cari tahu izin minimum yang diperlukan untuk menjalankan aplikasi dan menggunakannya.

Jika Anda meng-hosting beberapa situs, masing-masing dengan database sendiri, gunakan pengguna MySQL / Postgres yang terpisah untuk masing-masing, dan atur izin pada setiap pengguna sehingga mereka hanya memiliki akses ke database yang relevan. Sekali lagi ini akan mencegah skrip nakal merusak database aplikasi lain.

Suosin, HardenedPHP, mod_security dan sejenisnya juga sangat berharga, tetapi menggunakannya sebagai tambahan untuk konfigurasi yang dikunci dengan ketat, bukan sebagai ganti.


0

Suhosin memiliki biaya kinerja yang cukup besar, sehingga komentar "tidak ada biaya" agak tidak berarti.


2
Apa gunanya situs web yang diretas dengan cepat? :) hardened-php.net/suhosin/benchmark.html menyarankan 8,85% lebih lambat pada satu benchmark. Itu mungkin dapat diterima untuk manfaat keamanan yang diberikannya. Ini mungkin seharusnya komentar daripada jawaban.
David Pashley

Suhosin melindungi terutama terhadap serangan lokal. Jadi, jika Anda membagikan server Anda kepada orang-orang yang tidak Anda percayai, ini mungkin sebanding dengan perlambatannya. Jika Anda memiliki server Anda sendiri, atau slice vm Anda sendiri, saya tidak mengerti intinya.

0

Apakah Anda mencari beberapa saran dasar firewall / topologi? Saya suka ide menggunakan hal-hal seperti pound untuk mencegah akses langsung ke server web PHP dari internet yang tidak dicuci. Dengan begitu Anda juga dapat memisahkan server web dari bagian lain jaringan Anda juga.


Tidak, saya mencari cara untuk meningkatkan keamanan runtime PHP.
David Pashley

0

Menggunakan Suhosin / mod_security / SuPHP tentu akan membuat server PHP Anda aman. Menonaktifkan fungsi-fungsi tertentu seperti exec, passthru, sistem dan escapeshellcmd akan banyak membantu juga.


1
Bukankah escapeshellcmd () hanya digunakan untuk menghindari string? Itu tidak menyediakan cara apapun untuk mengeksekusi suatu proses. Bagaimana seseorang dapat menggunakannya untuk menimbulkan masalah?
David Pashley
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.