Newsgroup: it.comp.www.php
Titolo: istruzione eval()

L' utilizzo di eval() è uno dei cavalli di battaglia delle sql 
injection.
 
In effetti questo funziona sempre:
 
<?php
echo '<br>---<br>';
eval("\$a = 'eval nr. 1'; echo(\$a); echo('<br>'); \$b='rse uno'; 
echo(\$b);"); 	//eval nr. 1
			//rse uno
 
echo '<br>---<br>';
$z = eval("\$a = 'eval nr. 2'; echo(\$a); echo('<br>'); \$b='rse due'; 
echo(\$b);"); 	//eval nr. 2
				//rse due
 
echo '<br>---<br>';
$y = addslashes(eval("\$a = 'eval nr. 7'; echo(\$a); echo('<br>'); 
\$b='rse sette'; echo(\$b);"));	//eval nr. 7
							//rse sette
?>
 
Volendo evitare cose come suhosin o uso di linguaggi diversi dal php, 
ero speranzoso che ci fosse un modo di intercettare eval( da un
.htaccess
 
Ho provato alcune combinazioni ma niente.
 
Un aiuto?
Grazie.
 
-- 
Alex
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

.htaccess
 
Cioè: tu vuoi usare eval(), ma vuoi che il codice sottoposto a eval() non possa
a propria volta usare eval(), riconoscendo la funzione mediante blacklist?
 
Abbi pazienza, ma stai facendo un errore nel correggere un errore.
 
1) eval() non si usa. Punto. La necessità di usare eval() è un errore fatale, è
   tipo errore di sintassi. Se in un punto del codice ti viene fuori che *devi*
   usare eval(), debugga il progetto a ritroso finché non trovi l'errore.
 
2) usare una blacklist e, per esempio, disattivare eval(), non ti aiuta molto -
   perché i modi di farti danni sono molti di più. Reflection. Create_Function.
   Assert. E di sicuro me ne dimentico due o tre.
 
   Chiudere la porta è meglio che nulla, ma c'è la finestra che è aperta, ed il
   camino largo abbastanza da passarci, e giù in cantina il muro che separa dal
   vecchio acquedotto asciutto è fatto di mattoni a secco senza neanche malta.
 
Se posso dare un consiglio, rielabora il codice per non aver bisogno di eval().
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 
 
Intercettare per fare cosa?
Eval non è una funzione, ma un costrutto del linguaggio: non lo puoi bloccare
(tipo via php.ini), usare con funzioni variabili, etc.etc.
 
Ciao!

 Leonardo
 
Bye.


 Ciao!
 
Bye!


 
 
Se hai il rischio che quello che c'è sullo URL di richiesta, query string
compresa, finisca il qualche modo per essere eseguito, i tuoi problemi sono
ben altri! :)
Tendenzialmente se nel tuo codice non ci sono eval() o forti abusi di un
motore di templating, non vedo come qualcosa negli URL possa essere eseguito,
altri eval() inclusi.
 
Se ti serve solo un filtro sugli URL comunque basta una regola di rewrite sul
webserver.
 
Ciao!

siti fatti con joomla che ne fa un discreto uso (legittimo).
 
Mah, ho trovato un esempio qui
 
 
https://groups.google.com/forum/#!topic/joomla-dev-cms/p8hVgAw3Mas
 
 
...e, consapevole che mi sto cacciando in una polemica, sono d'accordo che sia un
uso legittimo... nella misura in cui è legittimo programmare da niubbi.
 
Voglio dire, in quel punto (ad esempio) serviva un expression parser. Bene. Ce ne
sono a decinaia che usano sintassi libera; se poi uno si contenta di una sintassi
più restrittiva se lo può fare ad hoc con una manciata di regexp. C'è il caching,
se uno si preoccupa delle performance.
 
Con eval() si fa prima? Sicuro. E anche a dare tre mani di vernice senza lasciare
asciugare si fa prima. Piccolo dettaglio: viene fuori una fetenzia :-)


 Leonardo
 
Bye


 Per essere eseguita, basta chiamarla per nome ...
 
Il punto è: chi la chiama per nome?
 
Se è il tuo codice a farlo, vuol dire che tu stai usando eval per 
eseguire qualcosa che l'utente ti ha mandato, e qui il problema è tuo.
 
Se viene eseguito perchè permetti all'utente di scrivere nello spazio 
pubblico del sito (upload area o simile), allora gli basta caricare un 
file .php e andarci subito dopo. Non gli serve eval().
 
Praticamente tutti gli altri casi ricadono in queste due casistiche e 
nella loro combinazione.
 
Se usi un motore di templating, tipo twig, che usa eval per motivi 
prestazionali, e gli passi roba creata dall'utente, ricadi nel primo 
caso. Se, sempre in twig, disabiliti l'escaping sull'output di una 
variabile caricata dall'utente, e lui carica php, ricadi nel secondo 
caso (ma può caricare anche codice js per CSRF e simile).
 
Se stai usando plugin joomla che usano male eval, non usarli. O non 
usare joomla. :)
 
Insomma, come dice Leonardo, intercettare eval è forse l'ultimo dei tuoi 
problemi di sicurezza.
 
Bye.
 

 Bye.


buchi o meno, bisogna che ti accorgi per tempo del piccolo file nocivo.
 
E, in quel caso, famd is your friend (per dire). Meglio ancora SELinux. Pure
Windows ha i suoi mezzi, ed è quasi tutto dire.
 
Naturalmente lì c'è da lavorare per altri versi (così come con AppArmor). Ma
l'operazione di tightening è soggetta a qualche cosa come le tre leggi della
termodinamica: c'è una certa quantità di giramento di scatole da sorbirsi, e
qualunque tentativo di ridurla, anche se lì per lì ha successo, alla fine si
rivela averla aumentata.


 Leonardo
 
Bye!
