Quali sono gli svantaggi dell'utilizzo del codice filtro PHP in blocchi, nodi, views-args, ecc.?

Ho visto molte volte persone che dicevano di non usare il filtro PHP / PHP personalizzato (dall'interfaccia utente di Drupal) in blocchi, nodi, viste-argomenti, regole, ecc. Ho cercato un po 'e non ho trovato molto, sembra questa è una best practice di Drupal che tutti "sanno".

Capisco che rappresenta un potenziale rischio per la sicurezza soprattutto nelle mani degli utenti finali o delle persone nuove di Drupal o PHP, ma come sviluppatore / costruttore di siti quali sono i motivi reali per non utilizzare PHP personalizzato dall'interfaccia utente di Drupal?

Alcuni motivi:

• Il codice nel database non può essere controllato in base alla versione ed è anche più difficile da trovare in generale in seguito.
• Eval () 'd code è molto più lento di qualcosa di hardcoded in un file.
• Se c'è un errore da qualche parte in quel codice, otterrai un messaggio di errore molto inutile (errore nel codice eval () 'alla riga 3) e potresti anche aver attraversato il tuo database manualmente per trovare e correggere l'errore. Se si trova all'interno di un blocco che viene visualizzato in tutte le pagine e, ad esempio, si verifica un errore irreversibile.
• Quanto sopra è vero anche durante l'aggiornamento da Drupal 6 a 7 e qualsiasi API utilizzata è stata modificata. Quindi dovrai eseguire il porting del codice durante la migrazione. Se il codice si trova in un modulo, è possibile portarlo in anticipo, testarlo e distribuirlo solo sul nuovo sito. All'interno di un nodo o blocco, funzionerà solo con Drupal 6 o 7.
• Scrivere e mantenere quel codice è anche più difficile, perché stai lavorando in un campo di testo all'interno del tuo browser. Avere in un modulo consente di utilizzare un editor / IDE con evidenziazione della sintassi, completamento automatico e così via.
• C'è sempre la possibilità di una configurazione errata che consente alle persone di accedere a un formato / blocco di testo / qualunque cosa con l'esecuzione di php abilitata. Se php.module (in D7, D6 non è così rigoroso, ad esempio per le regole di accesso ai blocchi) non è nemmeno abilitato, quel rischio è già molto più basso.
• Se il tuo CMS consente l'esecuzione di PHP, un utente malintenzionato che trova una vulnerabilità di sicurezza di XSS o escalation di privilegi può ora utilizzare il tuo server per cose estremamente dannose (come parte di un DDOS, invio di spam, hosting di malware, hacking in altri siti / database sul server, hackerando altri server della rete che potrebbero essere protetti da firewall). Oltre a rendere le piccole vulnerabilità più dolorose, questo rende il sito un obiettivo di attacco più probabile se si sa che può essere utilizzato per eseguire php.

Potrebbero esserci più motivi, ma dovrebbe bastare :)

È difficile eseguire il debug e la manutenzione di questo codice. Non conosco alcun modo per utilizzare il controllo versione per questo tipo di codice php.

Ed è davvero un potenziale rischio per la sicurezza delle persone che non conoscono Drupal o PHP,

Considerando il caso del filtro PHP utilizzato in un nodo, il motivo per non usarlo è che si limitano gli utenti che possono modificare quel nodo, se non si desidera consentire a tutti gli utenti di utilizzare il filtro PHP.
Piuttosto che usare il filtro PHP, è meglio usare un modulo personalizzato che sostituisce il testo specifico nel contenuto del nodo con il risultato del codice che esegue (senza usare eval()), o che aggiunge il proprio testo al contenuto del corpo dei nodi. In questo caso, qualsiasi utente può modificare il nodo, senza disporre dell'autorizzazione per aggiungere codice PHP arbitrario che viene quindi eseguito dal filtro PHP.

In generale, è meglio evitare eval()perché diminuisce la leggibilità del codice, la capacità di prevedere il percorso del codice (e le possibili implicazioni di sicurezza di esso) prima del runtime e quindi la possibilità di eseguire il debug del codice.

A parte uno sviluppo o un sito di test, non abiliterei il filtro PHP o utilizzerei il codice PHP che viene passato eval().

Il filtro PHP è stato rimosso da Drupal 8. Ora è un modulo di terze parti , non coperto dalla politica di consulenza sulla sicurezza . Questo è probabilmente un motivo in più per non usarlo nei server di produzione (se i motivi già indicati non ti hanno convinto).

Come soluzione per i vari problemi sopra specificati - difficoltà di manutenzione del codice, controllo della versione, ricerca degli errori, hai questa possibilità leggermente "klugey":

Crea funzioni (denominale attentamente, in base a ciò che fanno) in alcuni file che sono sempre inclusi: se hai un modulo personalizzato che stai scrivendo per il sito, è un ottimo posto per inserire queste funzioni. Il php che inserisci allora è semplicemente: return my_specialfunc($somevar);- $somevarqui potenzialmente l'oggetto del nodo su cui ha lavorato, o qualunque altra variabile sia rilevante qui.

Trovo che di solito voglio ancora la flessibilità, in alcuni punti, di chiamare il mio codice. Usando questa tecnica, mantenere il codice è facile poiché si tratta semplicemente di modificare la funzione nel file. L'individuazione degli errori è semplice poiché la funzione verrà visualizzata in un backtrace.

Si noti, tuttavia, che ciò non risolve i potenziali problemi di sicurezza. Questi dipendono in gran parte dalla sicurezza del nucleo di Drupal. In generale, il codice contenuto nel database è spesso un tallone di sicurezza per le achille: le funzionalità che usano il codice contenuto nel database tendono ad essere molto più inclini allo sfruttamento e la sicurezza che li circonda deve essere estremamente rigorosa. Tuttavia, Drupal è stato in generale abbastanza bravo a mantenere la sicurezza per questi problemi: sono sorti e quindi rapidamente rattoppati / risolti con nuove versioni.

Ecco il motivo della vulnerabilità della sicurezza per evitare di concedere questa autorizzazione agli utenti se non si desidera che gli utenti non amministratori modifichino direttamente il db.

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

Hacking delle credenziali del db Drupal

Piuttosto che fare qualcosa del genere return functionname($object), sarebbe meglio usare il sistema token / filtri per quanto possibile. Esistono moduli come Inserisci vista e Incorpora nodo che possono aiutare in circostanze comuni in cui le persone vorrebbero incorporare PHP in nodi o corpi di blocchi.

Dovresti preoccuparti della portabilità dei tuoi dati. E se migrassi i tuoi nodi da drupal 7 a drupal 8 e ci fosse del testo del corpo di qualche nodo <?php whatever_function_that_does_not_exist_anymore(); ?>?

Non pensare al tuo progetto entro 5 mesi ma entro 5 anni. A mio avviso, aggiornamenti, buone pratiche e portabilità sono aspetti importanti di qualsiasi buon progetto IT.

L'utilizzo di moduli con meno contributi possibili è anche un aspetto di questo.