it-swarm.it

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

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

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

95
Laxman13

Alcuni motivi:

  • Il codice nel database non può essere controllato in base alla versione ed è anche più difficile da trovare in generale in seguito.
  • Il codice Eval () 'd è molto più lento di qualcosa codificato 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 su tutte le pagine e, ad esempio, si verifica un errore irreversibile.
  • Quanto sopra è vero anche quando si aggiorna da Drupal da 6 a 7 e qualsiasi API utilizzata è stata modificata. Quindi è necessario 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. Avendolo in un modulo ti consente di utilizzare un editor/IDE con evidenziazione della sintassi, completamento automatico e così via.
  • Esiste 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 ora può utilizzare il tuo server per cose estremamente dannose (come parte di un DDOS, invio di spam, hosting di malware , l'hacking in altri siti/database sul server, l'hacking in altri server della rete che potrebbero essere dietro i firewall. Oltre a rendere più dolorose le piccole vulnerabilità, questo rende il sito un obiettivo di attacco più probabile se si sa che può essere usato per eseguire php.

Potrebbero esserci più motivi, ma dovrebbe bastare :)

129
Berdir

È 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,

17
ya.teck

Considerando il caso del 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 per usare il filtro PHP.
Piuttosto che usare il 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 arbitrario PHP codice 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 PHP, o utilizzare PHP che viene passato a eval() .

Il filtro PHP è stato rimosso da Drupal 8. Ora è n modulo di terze parti , non coperto dal - 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).

14
kiamlaluno

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 the Drupal db credentials

11
lolcode

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); - $somevar qui essendo potenzialmente l'oggetto nodo su cui si è 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 Drupal core. In generale, il codice contenuto nel database è spesso un tallone di sicurezza di Achille - le funzionalità che usano codice contenuto nel database tendono ad essere molto più inclini a lo sfruttamento e la sicurezza che li circonda devono essere estremamente rigorosi. Tuttavia, Drupal è stato in generale abbastanza bravo a mantenere la sicurezza per questi problemi: sono sorti e quindi rapidamente rattoppati/risolti con nuove versioni .

11
James

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

7
Evan Donovan

Dovresti preoccuparti della portabilità dei tuoi dati. Cosa succede se si esegue la migrazione dei nodi da drupal 7 a drupal 8 e il testo del corpo di alcuni nodi contiene <?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'uso di moduli con meno contributi possibili è anche un aspetto di questo.

0