Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20965 > unrolled thread

istruzione eval()

Back to article view | Back to it.comp.www.php

Contents

  istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-21 13:36 +0200
    Re: istruzione eval() Leonardo Serni <lserni@gmail.com> - 2016-06-21 18:31 +0200
      Re: istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-21 20:21 +0200
        Re: istruzione eval() fmassei@gmail.com - 2016-06-21 12:00 -0700
        Re: istruzione eval() Leonardo Serni <lserni@gmail.com> - 2016-06-22 01:37 +0200
          Re: istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-22 11:45 +0200
            Re: istruzione eval() Alessandro Pellizzari <shuriken@amiran.it> - 2016-06-22 11:27 +0100
              Re: istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-22 14:06 +0200
            Re: istruzione eval() Leonardo Serni <lserni@gmail.com> - 2016-06-22 15:44 +0200
              Re: istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-22 19:41 +0200
    Re: istruzione eval() fmassei@gmail.com - 2016-06-21 09:35 -0700
      Re: istruzione eval() Alex <tommaso5ita@yahoo.it> - 2016-06-21 20:24 +0200

#20965 — 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: news@netfront.net ---

[toc] | [next] | [standalone]

#20968

On Tue, 21 Jun 2016 13:36:10 +0200, Alex <tommaso5ita@yahoo.it> wrote:

>L' utilizzo di eval() è uno dei cavalli di battaglia delle sql injection.

A dirti proprio la verità, no :-D

>In effetti questo funziona sempre:

><?php
>echo '<br>---<br>';
>eval("\$a = 'eval nr. 1'; echo(\$a); echo('<br>'); \$b='rse uno'; 

Scusa, in che senso funziona? L'eval che fa partire tutto ce lo hai messo tu...

>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

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

[toc] | [prev] | [next] | [standalone]

#20971

Leonardo Serni ci ha detto :
>
> Se posso dare un consiglio, rielabora il codice per non aver bisogno di 
> eval().
>
Infatti non ne ho nessun bisogno :-)
Devo essermi spiegato male.

Mi interessa trovare qualcosa che lo intercetti (alias lo fermi) quando 
è presente la parlina eval( in una QUERY_STRING  oppure in un 
REQUEST_URI

Qualcosa che non sia suhosin o un filtro scritto in altri linguaggi.
Peraltro, disabilitare del tutto l'istruzione può porre dei problemi ai 
siti fatti con joomla che ne fa un discreto uso (legittimo).

> Leonardo

Bye.

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20974

On Tuesday, June 21, 2016 at 2:21:49 PM UTC-4, Alex wrote:
> Mi interessa trovare qualcosa che lo intercetti (alias lo fermi) quando 
> è presente la parlina eval( in una QUERY_STRING  oppure in un 
> REQUEST_URI
> 

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!

[toc] | [prev] | [next] | [standalone]

#20975

On Tue, 21 Jun 2016 20:21:45 +0200, Alex <tommaso5ita@yahoo.it> wrote:

>> Se posso dare un consiglio, rielabora il codice per non aver bisogno di 
>> eval().

>Infatti non ne ho nessun bisogno :-)
>Devo essermi spiegato male.

>Mi interessa trovare qualcosa che lo intercetti (alias lo fermi) quando 
>è presente la parlina eval( in una QUERY_STRING  oppure in un 
>REQUEST_URI

Ma perché? Sei hai del codice ben scritto, "eval" lo puoi fare passare, perché fa
gli stessi danni di "vela" e "vale" -- nessuno.

Se hai del codice scritto male, dove eval() può fare dei danni, allora tappare le
porte a eval() non ottiene assolutamente niente. Perché per poter funzionare, una
sequenza come "eval" deve essere _ESEGUITA_.

E qualunque cosa che _ESEGUA_ eval() eseguirà allegramente assert(). Allora, devi
bloccare anche assert.

Ma anche shell_exec, e lì si apre un barile di vermi.

E i mille e un modo con cui si può fare passare una stringa che htaccess vedrà in
un modo, e il PHP in un altro (trucchi con UTF8, reassembling, e via andando).

>Qualcosa che non sia suhosin o un filtro scritto in altri linguaggi.
>Peraltro, disabilitare del tutto l'istruzione può porre dei problemi ai 
>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
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#20976

Leonardo Serni scriveva il 22/06/2016 :
>
> Ma perché? Sei hai del codice ben scritto, "eval" lo puoi fare passare, 
> perché fa gli stessi danni di "vela" e "vale" -- nessuno.
>
> Se hai del codice scritto male, dove eval() può fare dei danni, allora 
> tappare le porte a eval() non ottiene assolutamente niente. Perché per poter 
> funzionare, una sequenza come "eval" deve essere _ESEGUITA_.
>
>
Per essere eseguita, basta chiamarla per nome ...
O genera un errore o viene eseguita.

Ci sono versioni di cms che sono particolarmente sensibili alla cosa, 
come mio malgrado ho notato fin nei dettagli ultimamente.

> E qualunque cosa che _ESEGUA_ eval() eseguirà allegramente assert(). Allora, 
> devi bloccare anche assert.
>
> Ma anche shell_exec, e lì si apre un barile di vermi.
>
> E i mille e un modo con cui si può fare passare una stringa che htaccess 
> vedrà in un modo, e il PHP in un altro (trucchi con UTF8, reassembling, e via 
> andando).
>

Shell_exec(), file_put_contents(), base64_ sono utili, le altre servono 
solo agli hackers.
Credo che non ci sia nulla per cui è indispensabile eval().

C'è una costante nei tentativi malevoli che vanno a bersaglio, ovvero 
riescono a costruire una "testa di ponte". Un piccolo file che viene 
ripreso in seconda battuta.
Siccome mi sembra difficile sapere se qualcosa che hai installato ha 
buchi o meno, bisogna che ti accorgi per tempo del piccolo file nocivo.

Un .htaccess  aiuta.
Nell' insieme, anche se il codice non è niente di speciale, si dovrebbe 
riuscire ad intercettare quasi tutto ciò che non va.

In effetti chiedevo solo se qualcuno ha già delle RewriteRule adatte.

>
> Mah, ho trovato un esempio qui
>
> 	https://groups.google.com/forum/#!topic/joomla-dev-cms/p8hVgAw3Mas
>
Sì, joomla ha parecchi eval().
In alcuni casi c'è anche codice che testa se eval() è abilitato o no. 
Se non è abilitato fa le sue cose in un altro modo.
In altri casi si pianta tutto.
Quindi non si può disabilitare eval.

> Leonardo

Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20977

On 22/06/2016 10:45, Alex wrote:

> Leonardo Serni scriveva il 22/06/2016 :

>> Se hai del codice scritto male, dove eval() può fare dei danni, allora
>> tappare le porte a eval() non ottiene assolutamente niente. Perché per
>> poter funzionare, una sequenza come "eval" deve essere _ESEGUITA_.

> 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.

[toc] | [prev] | [next] | [standalone]

#20980

Dopo dura riflessione, Alessandro Pellizzari ha scritto :
>
> Insomma, come dice Leonardo, intercettare eval è forse l'ultimo dei tuoi 
> problemi di sicurezza.
>

Non sono così grandi, eh.
In realtà ho chiesto un firewall e quello è ok.

La discussione è interessante e accademica.

> Bye.

Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20983

On Wed, 22 Jun 2016 11:45:25 +0200, Alex <tommaso5ita@yahoo.it> wrote:

>Siccome mi sembra difficile sapere se qualcosa che hai installato ha 
>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
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#20990

Scriveva Leonardo Serni mercoledì, 22/06/2016:
>
> 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.
>

Le tre leggi sono sempre inviolabili! :-)
> Leonardo

Bye!

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20969

On Tuesday, June 21, 2016 at 7:36:14 AM UTC-4, Alex wrote:
> L' utilizzo di eval() è uno dei cavalli di battaglia delle sql 
> injection.
> 

Non usare eval nel tuo codice, a meno che non possa proprio fare altrimenti.

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

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!

[toc] | [prev] | [next] | [standalone]

#20972

fmassei@gmail.com scriveva il 21/06/2016 :
>
> 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.
>

Decisamente mi sono spiegato male.

Ovviamente intercettare per rigettare la chiamata http al sito!

Personalmente non lo adopero proprio, eval(), ma esiste e allora c'è 
chi lo adopera, legittimamente e meno.

> Ciao!

Bye!

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web