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


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

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


1
Seperti biasa, itu tergantung situasi! Jika Anda hanya memerlukan cetakan $ blok dasar di bagian bawah halaman Views Anda di 'footer tampilan', mungkin ideal untuk melakukannya hanya melalui gui dibandingkan dengan menulis seluruh file tpl seluruh hanya untuk tujuan itu. Ini tentu saja juga tergantung pada peran situs dan faktor-faktor lain: Tenggat waktu yang ketat? Situs komunitas pengguna? Atau hanya situs informasi? Apakah ini penting untuk operasi bisnis? dll ... tergantung.
Patoshi パ ト シ

Jawaban:


Beberapa alasan:

  • Kode dalam basis data Anda tidak dapat dikontrol versi dan juga lebih sulit ditemukan secara umum nanti.
  • Kode Eval () jauh lebih lambat daripada sesuatu yang dikodekan 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 memutakhirkan dari Drupal 6 ke 7 dan API apa pun yang Anda gunakan diubah. Jadi, Anda harus porting kode Anda saat bermigrasi Jika kode ada dalam modul, Anda bisa porting terlebih dahulu, mengujinya, dan hanya menyebarkannya 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 penyorotan 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 kini dapat menggunakan server Anda untuk hal-hal yang sangat berbahaya (sebagai bagian dari DDOS, mengirim spam, hosting malware, meretas situs / database 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 dapat digunakan untuk mengeksekusi php.

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


3
Daftar yang bagus :) semoga akan menjadi sumber bagi orang lain
Laxman13

3
@ Laxman13: "kepada orang lain" ... dan untuk Anda juga! : D @Berdir: +1, aspek yang sangat bagus. Ngomong-ngomong, Anda tidak harus menulis seluruh kode dalam bidang teks, karena Anda juga dapat memasukkan file di sana. Misalnya, Anda dapat meletakkan hanya satu baris di bidang teks: require_once $_SERVER['DOCUMENT_ROOT'].'/sites/all/themes/myTheme/php/stuff.php';dan menulis sisa kode di editor IDE / teks Anda. Terkadang ini bukan pekerjaan mudah atau akan membutuhkan waktu yang sangat lama untuk membuat modul sendiri bahkan sebagai pengembang PHP yang baik. Satu contoh singkat: Tindakan Bersyarat Ubercart. Tapi memang benar itu bukan hal yang baik untuk menyimpan kode kita di db.
Sk8erPeter

Maksud saya, misalnya modul Tindakan UC UC memiliki GUI yang sangat hebat yang menghemat banyak waktu dari keharusan menulis kode panjang kita sendiri. Anda dapat membuat tindakan yang sangat kompleks dalam hitungan menit dengan metode "next-next-finish" pada GUI. Tetapi mungkin Anda ingin memperluas fungsionalitas dengan beberapa kode Anda sendiri - dalam banyak kasus, sama sekali tidak layak mengembangkan modul untuk tujuan itu.
Sk8erPeter

1
+1000 - Saya telah melihat begitu banyak proyek yang dibakar oleh hampir setiap poin dalam daftar ini. Hanya ada satu waktu sepanjang hidup saya bahwa menggunakan modul PHP adalah satu-satunya cara untuk menyelesaikan sesuatu dengan cara yang waras, dan itu hanya karena masalah dengan D6 yang diperbaiki di D7.
geerlingguy

Terima kasih atas jawaban detail Anda untuk pertanyaan ini. Saya menemukan situasi saat bekerja di Drupal, bahwa ketika kita perlu menambahkan tautan di 'editor teks', kita perlu menggunakan kode php di 'filter teks' jika tidak maka tidak akan berfungsi seperti yang diharapkan.
Jayendra Kainthola

Kode ini sulit 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,


1
Nah, jika konfigurasi blok diekspor ke kode dengan modul fitur itu tidak masalah untuk menempatkan potongan php di bawah kontrol versi.
ya.teck

Mempertimbangkan kasus filter PHP yang digunakan dalam sebuah simpul, alasan untuk tidak menggunakannya adalah karena Anda membatasi pengguna yang dapat mengedit simpul 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 dari kode yang dieksekusi (tanpa menggunakan eval()), atau yang menambahkan teksnya sendiri ke isi tubuh dari node. Dalam hal ini, setiap pengguna dapat mengedit simpul, tanpa memiliki izin untuk menambahkan kode PHP sewenang-wenang 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 uji, saya tidak akan mengaktifkan filter PHP, atau menggunakan kode PHP yang diteruskan ke eval().

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


Sebagai solusi untuk berbagai masalah yang ditentukan di atas - kesulitan pemeliharaan kode, kontrol versi, penemuan kesalahan, Anda memiliki kemungkinan "klugey" 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);- di $somevarsini 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 sebagian besar tergantung pada keamanan inti Drupal. Secara umum, kode yang berisi basis data seringkali menjadi kelemahan keamanan - fungsionalitas yang menggunakan kode yang berisi basis data cenderung jauh lebih rentan terhadap eksploitasi, dan keamanan di sekitarnya 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.


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


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


Anda harus peduli tentang portabilitas data Anda. Bagaimana jika Anda memigrasi node Anda dari drupal 7 ke drupal 8 dan teks tubuh beberapa node ada <?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.

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.