it-swarm-id.com

Apa kerugian menggunakan PHP Filter kode dalam blok, node, views-args, dll?

Saya telah melihat berkali-kali orang mengatakan untuk tidak menggunakan filter PHP/PHP khusus (dari Drupal UI) di blok, node, views-args, aturan, dll. Saya telah mencari-cari sedikit dan belum ditemukan banyak, sepertinya ini adalah Drupal praktik terbaik yang semua "hanya tahu".

Saya mengerti ini menimbulkan risiko keamanan potensial terutama di tangan pengguna akhir atau orang yang baru menggunakan Drupal atau PHP, tetapi sebagai pengembang/pembangun situs apa alasan sebenarnya untuk tidak menggunakan kustom PHP dari Drupal UI?

95
Laxman13

Beberapa alasan:

  • Kode dalam basis data Anda tidak dapat dikontrol versi dan juga lebih sulit ditemukan secara umum nanti.
  • Kode Eval () 'adalah banyak lebih lambat dari sesuatu yang di-hardcode dalam file.
  • Jika ada kesalahan di suatu tempat dalam kode itu, Anda akan mendapatkan pesan kesalahan yang sangat tidak membantu (error in eval () d code di baris 3) dan Anda bahkan mungkin harus melalui database Anda secara manual untuk menemukan dan memperbaiki kesalahan tersebut. Jika ada di dalam blok yang ditampilkan pada semua halaman dan menghasilkan kesalahan fatal sepanjang waktu misalnya.
  • Hal di atas juga berlaku ketika meningkatkan dari Drupal 6 ke 7 dan API apa pun yang Anda gunakan diubah. Jadi, Anda harus mem-porting kode Anda saat bermigrasi. Jika kode tersebut ada dalam modul, Anda dapat port terlebih dahulu, uji, dan hanya sebarkan di situs baru. Di dalam node atau blok, itu hanya akan berfungsi dengan Drupal 6 atau 7.
  • Menulis dan mempertahankan kode itu juga lebih sulit, karena Anda bekerja di bidang teks di dalam browser Anda. Setelah itu dalam modul memungkinkan Anda untuk menggunakan editor/IDE dengan highlight sintaksis, autocomplete dan sebagainya.
  • Selalu ada kemungkinan kesalahan konfigurasi yang memberikan orang akses ke format teks/blok/apa pun dengan eksekusi php diaktifkan. Jika php.module (dalam D7, D6 tidak terlalu ketat, misalnya untuk aturan akses blok) bahkan tidak diaktifkan, risiko itu sudah jauh lebih rendah.
  • Jika CMS Anda memungkinkan eksekusi PHP maka penyerang yang menemukan kerentanan keamanan XSS atau peningkatan hak istimewa sekarang dapat menggunakan server Anda untuk hal-hal yang sangat berbahaya (sebagai bagian dari DDOS, mengirim spam, hosting malware) , meretas ke situs/basis data lain di server, meretas ke server lain di jaringan yang mungkin berada di belakang firewall) .Selain membuat kerentanan kecil lebih menyakitkan, ini membuat situs ini menjadi target serangan yang lebih mungkin jika diketahui bahwa ia dapat digunakan untuk mengeksekusi php.

Mungkin ada lebih banyak alasan, tetapi itu sudah cukup :)

129
Berdir

Kode ini sulit untuk di-debug dan dipelihara. Saya tidak tahu cara menggunakan kontrol versi untuk kode php semacam itu.

Dan itu benar-benar risiko keamanan potensial bagi orang yang baru mengenal Drupal atau PHP,

17
ya.teck

Mempertimbangkan kasus filter PHP yang digunakan dalam sebuah node, alasan untuk tidak menggunakannya adalah karena Anda membatasi pengguna yang dapat mengedit node itu, jika Anda tidak ingin mengizinkan semua pengguna untuk menggunakan filter PHP.
Daripada menggunakan filter PHP, lebih baik menggunakan modul khusus yang menggantikan teks tertentu dalam konten node dengan hasil kode yang dijalankan (tanpa menggunakan eval()), atau yang menambahkan teksnya sendiri ke isi tubuh dari node. Dalam hal ini, setiap pengguna dapat mengedit node, tanpa memiliki izin untuk menambahkan sewenang-wenang PHP kode yang kemudian dijalankan oleh filter PHP.

Secara umum, lebih baik untuk menghindari eval() karena mengurangi keterbacaan kode, kemampuan bagi Anda untuk memprediksi jalur kode (dan kemungkinan implikasi keamanan itu) sebelum runtime, dan karenanya kemampuan untuk men-debug kode .

Terpisah dalam pengembangan atau situs pengujian, saya tidak akan mengaktifkan filter PHP, atau menggunakan kode PHP yang diberikan ke eval() .

Filter PHP telah dihapus dari Drupal 8. Sekarang modul pihak ketiga , tidak tercakup dari - kebijakan penasehat keamanan . Ini mungkin merupakan alasan lebih untuk tidak menggunakannya di server produksi (jika alasan yang sudah diberikan tidak meyakinkan Anda).

14
kiamlaluno

Berikut adalah alasan kerentanan keamanan untuk menghindari memberikan izin ini kepada pengguna Anda jika Anda tidak ingin pengguna non-admin Anda memodifikasi db secara langsung.

<?php
echo file_get_contents(dirname(__FILE__)."/../sites/default/settings.php");
?>

Meretas kredensial Drupal db

11
lolcode

Sebagai solusi untuk berbagai masalah yang ditentukan di atas - kesulitan pemeliharaan kode, kontrol versi, pencarian kesalahan, Anda memiliki kemungkinan "klugey" yang sedikit ini:

Buat fungsi (beri nama dengan hati-hati, sesuai dengan fungsinya) di beberapa file yang selalu disertakan - jika Anda memiliki modul khusus yang Anda tulis untuk situs tersebut, itu adalah tempat yang tepat untuk meletakkan fungsi-fungsi ini. Php yang Anda masukkan hanyalah: return my_specialfunc($somevar); - $somevar di sini berpotensi menjadi objek simpul yang dikerjakan, atau variabel apa pun lainnya yang relevan di sini.

Saya menemukan bahwa saya biasanya masih menginginkan fleksibilitas, di beberapa tempat, untuk memanggil kode saya sendiri. Dalam menggunakan teknik ini, memelihara kode itu mudah karena itu hanya masalah memodifikasi fungsi dalam file. Bercak kesalahan mudah karena fungsinya akan muncul di backtrace.

Perhatikan, bagaimanapun, bahwa ini tidak menyelesaikan masalah keamanan potensial. Ini sangat tergantung pada keamanan inti Drupal. Secara umum, kode yang berisi basis data sering kali merupakan kelemahan keamanan) - fungsionalitas yang menggunakan kode yang berisi basis data cenderung jauh lebih rentan terhadap eksploitasi, dan keamanan di sekitar mereka harus ekstra ketat. Namun, Drupal secara umum cukup baik dalam menjaga keamanan untuk masalah ini - mereka telah muncul dan kemudian dengan cepat ditambal/diselesaikan dengan rilis baru .

11
James

Daripada melakukan sesuatu seperti return functionname($object), akan lebih baik menggunakan sistem token/filter sejauh mungkin. Ada modul seperti Insert View dan Embed Node yang dapat membantu dengan keadaan umum di mana orang ingin menanamkan PHP dalam simpul atau blok badan.

7
Evan Donovan

Anda harus peduli tentang portabilitas data Anda. Bagaimana jika Anda memigrasikan node Anda dari drupal 7 ke drupal 8 dan teks tubuh beberapa node memiliki <?php whatever_function_that_does_not_exist_anymore(); ?> di dalamnya?

Jangan memikirkan proyek Anda dalam 5 bulan tetapi dalam 5 tahun. Pembaruan, praktik yang baik, dan mudah dibawa adalah aspek penting dari setiap proyek TI yang baik menurut saya.

Menggunakan modul yang kurang berkontribusi mungkin juga merupakan salah satu aspek dari ini.

0