mysql_real_escape_string come si usa?

[andrea_kobe]

Salve forumisti.

Ho molti dubbi circa l'uso corretto della funzione mysql_real_escape_string.

Sul forum ho trovato questo script per rimuovere il magic_quotes. Funziona,infatti le query che prima andavano bene ora ovviamente creano problemi per via degli apici

<?php
function magicQuotesRemove(&$array) {

   if(!get_magic_quotes_gpc())

       return;

   foreach($array as $key => $elem) {

       if(is_array($elem))

           magicQuotesRemove($elem);

       else

           $array[$key] = stripslashes($elem);

   }

}

magicQuotesRemove($_GET);
magicQuotesRemove($_POST);
magicQuotesRemove($_COOKIE);
?>

Tornando alla funzione suddetta,come si usa?
Devo applicarla singolarmente alle variabili che recupero via post (se sì va applicata solo alle stringhe o anche ai valori numerici,alle date ecc? ) oppure costruisco prima la query e la applico solo alla stringa generata prima di darla in pasto a mysql_query?

Per rendere lo script portabile come faccio a fare in modo che se la funzione non è disponibile a causa della versione datata di php lo script funzioni lo stesso? (devo usare mysql_escape_string in questo caso,giusto)?

Grazie a chi mi chiarirà tutti i dubbi.

[piero.mac]

Pillola....

http://forum.html.it/forum/showthrea...ostid=10166292

[Lak3d]

ma perchè vi fate tutti questi problemi e non lasciate invece direttamente alla direttiva magic quotes il compito di farlo per voi?

Ok che recenteente ho scoperto che in termini di prestazioni non è il massimo, però se non dovete realizzare nulla di enorme non vedo il problema...

[ana4ever-vids]

Mi sembra che conoscere a fondo cosa si usa sia una cosa positiva! Non trovi???

[andrea_kobe]

Originariamente inviato da Lak3d
ma perchè vi fate tutti questi problemi e non lasciate invece direttamente alla direttiva magic quotes il compito di farlo per voi?

Ok che recenteente ho scoperto che in termini di prestazioni non è il massimo, però se non dovete realizzare nulla di enorme non vedo il problema...

Il problema è che in futuro ho letto che verrà eliminato, viene sconsigliato il suo utilizzo e vorrei fare qualcosa che funzioni a prescindere dalla configurazione specifica del server.

@piero.mac
Grazie per la segnalazione della pillola. E' molto ben fatta anche se non mi ha chiarito tutti i dubbi.
Nella sua pillola luca200 si è fatto una funzioncina che elimina lo slash se il magic_quotes è attivo e lo lascia inalterato se invece è disattivo. Poi richiama la sua funzione e la applica al valore ricevuto via post. Quindi se io nel mio form ho 10 campi devo richiamare la funzione 10 volte e sempre 10 volte applicare mysql_real_escape_string?

Anche sul manuale ci sono diversi esempi, alcune volte viene applicata a ogni singolo valore, tra i commenti c'è anche questa soluzione:

$_POST  = array_map('mysql_real_escape_string', $_POST);

Insomma, quale metodo devo seguire?

E che vantaggio ottengo dopo che ho già usato mysql_real_escape_string ad applicarci pure sprintf come leggo sul manuale in uno tra i tanti commenti?

Scusatemi ma sono nel pallone.

[mark2x]

Originariamente inviato da Lak3d
ma perchè vi fate tutti questi problemi e non lasciate invece direttamente alla direttiva magic quotes il compito di farlo per voi?

Ciò che è infatti il metodo peggiore........... :ignore:

Se in futuro verrà eliminata è solo perchè verranno aggiunte funzioncine migliori allo scopo... Ce n'è già una nuova nuova...

[Lak3d]

oh, io l'ho pure scritto che pare non sia conveniente in termini di prestazioni. Però se non si lavora con basi dati enormi che importa?
Vabbè che basta disabilitarla e usare la addslash...

[piero.mac]

Originariamente inviato da andrea_kobe
@piero.mac
Grazie per la segnalazione della pillola. E' molto ben fatta anche se non mi ha chiarito tutti i dubbi.
Nella sua pillola luca200 si è fatto una funzioncina che elimina lo slash se il magic_quotes è attivo e lo lascia inalterato se invece è disattivo. Poi richiama la sua funzione e la applica al valore ricevuto via post. Quindi se io nel mio form ho 10 campi devo richiamare la funzione 10 volte e sempre 10 volte applicare mysql_real_escape_string?

Non vorrei aggiungere confusione....

La ragione prima, e che e' ben descritta nella pillola, credo sia quella di poter avere per ogni tipo di DBMS la corretta gestione dell'appropriato carattere di escape.

Se magic quotes attivo applica a tutte le stringhe in ingresso alla pagina il carattere di escape generalizzato (il backslashes oppure l'apostrofo a seconda dell'impostazione) non e' che togliendolo migliori la prestazione, tanto ormai la cosa era fatta... ma lo fai per gestire nel modo corretto la tua stringa. Per migliorare la prestazione bisognerebbe "impedire" (magic_quote_gpc = OFF) alla funzione di fare questo lavoro, e lo potresti fare mettendo l'istruzione nel file .htaccess a prescindere dal settaggio del php.ini

Quando una funzione od un settaggio viene dato come "deprecato" significa che "si deve" abbandonare almeno a partire dagli script nuovi, per evitare che poi da "deprecato" diventi "eliminato" e lasci i nostri script nelle cosi' dette "brache di tela"

Per quanto riguarda il controllo direi che va applicato ad ogni variabile, allo stesso modo con cui applichi tutti gli altri controlli sui dati in ingresso.

Sprintf potrebbe essere usato per fare dei controlli sul tipo di dato che arriva da una variabile.... "per comporre" una stringa.... ma personalmente non mi piace. Se un dato non e' quello che mi aspetto vorrei gestirlo "prima" di inserirlo, per esempio, in una query.

[andrea_kobe]

Ti ringrazio piero.mac per la spiegazione. Sei stato molto gentile. Un'ultima domanda se posso.

Se devo fare una query semplice di questo tipo

delete from tabella where id = $id

è più corretta scritta come sopra oppure scritta così

delete from tabella where id = '$id'

con la variabile tra apici. Lo chiedo perchè mi sembra di aver letto che per ragioni di sicurezza è preferibile il metodo con gli apici. Vi risulta questa cosa? Grazie ancora.

[luca200]

Originariamente inviato da andrea_kobe
Se devo fare una query semplice di questo tipo

delete from tabella where id = $id

è più corretta scritta come sopra oppure scritta così

delete from tabella where id = '$id'

con la variabile tra apici. Lo chiedo perchè mi sembra di aver letto che per ragioni di sicurezza è preferibile il metodo con gli apici. Vi risulta questa cosa? Grazie ancora.

E' vero in parte.
Se quell'$id deve essere numerico e tu hai VERIFICATO che lo sia, gli apici diventano superflui.
Se non hai verificato la correttezza del dato, gli apici possono impedire una SQL Injection, ma in realtà non è detto, se non fai l'escape della stringa.
In sintesi, se fai tutti i controlli gli apici non servono.

Esempi basati sulla tua query: supponiamo che la variabile $id venga passata in query string e tu non controlli il suo contenuto

Chiamata dal browser: pagina.php?id=2 or 1=1
Query eseguita senza apici: delete from tabella where id = 2 or 1=1 (ti svuota la tabella!)
Query eseguita con apici: delete from tabella where id='2 or 1=1' (in questo caso la stringa fra apici viene "numericizzata" col valore 2, neutralizzando di fatto l'attacco ed eseguendo la query corretta).

Come vedi in questo caso gli apici ti hanno aiutato. Ma se la chiamata dal browser fosse questa:
pagina.php?id=2' or '1=1
Ecco che la query eseguita (con gli apici) diventa: delete from tabella where id='2' or '1=1'
E tu ti trovi di nuovo la tabella svuotata. In questo caso il rimedio sarebbe eseguire l'escape, che trasformerebbe la query in
delete from tabella where id='2\\' or \\'1=1'
E così otterresti lo stesso risultato visto nell'ultimo caso precedente, cioè attacco neutralizzato.

Tuttavia la soluzione più logica è verificare la numericità del dato; non ha infatti molto senso non fare questo controllo e poi affidarsi agli apici, che a loro volta sono efficaci solo in presenza di escape della stringa (che invece diventa superfluo quando sai che la stringa è numerica).
Fra l'altro, volendo ragionare in termini di portabilità, bisogna ricordare che alcune versioni di SQL, contrariamente a MySql, segnalano un errore se trovano fra apici un valore che è previsto come numerico.

Ricordo anche che con MySql 4.1 e la nuova estensione mysqli sono state introdotte le Prepared Statements che eliminano i problemi di SQL Injection