encoding dati per Mysql sicuro

Salve,
Dal mio sito (un blog) l'utente compila dei form che vengono inviati al database Mysql.

Per un mysql sicuro, a quanto ho capito, è conveniente salvare i dati nel mysql nella loro forma gia sicura, codificata... Senza tag HTML nè, soprattutto, virgolette e accenti.

Quali sono i presidi che mi conviene usare per fare questo? Ho visto che le possibilità sono tante: urlencode, addslashes, striptags e molti altri..

Al fine di evitare defacciamenti e SQL injection voi quali consigliate di fare? Urlencode è sufficiente?

Se è un campo di tipo TEXT o VARCHAR è meglio usare htmlspecialchars(), rende innocui i tags html e (con l'apposito parametro) anche le virgolette, evitando sql injections.
Se vuoi qualcosa di più restrittivo puoi sempre usare le espressioni regolari
Se il campo è un INT è sempre bene passarlo su funzioni di tipo intval()

[dementialsite]

A un livello iniziale è sufficiente realizzare una funzione ad-hoc tipo questa:

function encode_msg ($msg)
{
   $encoded = str_replace ("&", "&", $msg);
   $encoded = str_replace ("<", "&lt;", $encoded);
   $encoded = str_replace (">", "&gt;", $encoded);
   $encoded = str_replace ("\"", "&quot;", $encoded);

   return $encoded;
} 

In questo modo il testo scritto è mantenuto "così com'è":
- striptags(), invece, mi pare che i tag li elimini proprio e con quella non riusciresti mai a fare un forum di supporto per HTML
- addslashes() invece aggiunge dei backslash davanti a caratteri pericolosi quali le virgolette, gli apici o il backslash stesso, ma che in alcuni casi potrebbero risultare inutili
- urlencode() non ho ben presente cosa faccia... :-(

Certo, se poi devi anche "criptare" ulteriormente per evitare casini con i caratteri accentati, allora devi allungare ulteriormente quella funzione, continuando a sostituire il carattere "incriminato" con il suo encode HTML.

Stammi bene...

P.S. Ecco, come al solito hanno risposto prima di me...

A un livello iniziale è sufficiente realizzare una funzione ad-hoc tipo questa:

function encode_msg ($msg)
{
   $encoded = str_replace ("&", "&", $msg);
   $encoded = str_replace ("<", "&lt;", $encoded);
   $encoded = str_replace (">", "&gt;", $encoded);
   $encoded = str_replace ("\"", "&quot;", $encoded);

   return $encoded;
} 

- urlencode() non ho ben presente cosa faccia... :-(

Mi sembra l'opzione migliore, così decidi carattere per carattere cosa mettere o togliere.

- nota per Dementialsite:

urlencode() è la funzione che da

http://validator.w3.org/check?uri=http://pietrovischia.altervista.org/testxhtml.php

ti restituisce

http://validator.w3.org/check?uri=http%3A%2F%2Fpietrovischia.altervista.org%2Ftestxhtml.php

Ciao!!!

[Evcz]

occhio a fare l'escape degli apostrofi...

il carattere ' è quello usato di più in assoluto per fare injection... :/

ti consiglio questa lettura:
http://www.spidynamics.com/papers/SQ...WhitePaper.pdf

e poi un'occhiata alla funzione:
(tra l'altro il secondo esempio in questa pag fa capire perchè BISOGNA fare l'escape dell' " ' ") :)
http://it2.php.net/manual/en/functio...ape-string.php

poi su certi host c'è già attivo magic_quote, su altri no... quindi va fatto un controllo anche la per evitare di aggiungere escape doppi...

[dementialsite]

Ok... mi è bastato leggere qualche query "hackata" per vedere il pericolo apostrofi... però comunque non puoi sostituirlo con un codice HTML (esistono dei codici, ‘ e ’ mi sembra, che corrispondono però agli apostrofi che si usano sulla tastiera americana).

Allora, se si tratta di far digerire degli input strani a MySQL, dovrebbe bastare questa funzione:

function encode_for_sql ($msg)
{
   // in MySQL si può far "digerire" l'apostrofo in una stringa raddoppiandolo senza lasciare spazi
   return str_replace ("\'", "\'\'", $msg);
} 

Non buttare via la funzione di prima, ti può comunque servire (anzi, ti serve), se si tratta di VISUALIZZARE IN HTML un testo...

Statemi bene...

Anzitutto grazie a tutti voi siete grandi :)

Domanda:

Supponiamo che l'utente compili un campo form che sia il tipico campo di ricerca alla google per intenderci, e i dati vengano inviati con metodo GET.

Supponiamo che il dato in GET mandato dall'utente abbia un apostrofo.

A questo punto raccogliete i dati con un:

$search=addslashes($_GET['search']);

In questo modo avrete slashato l'apostrofo.

A questo punto possiamo fare la nostra bella QUERY SELECT con la variabile $search e vedere se $search è contenuto nel database.

Se i dati nel database NON sono stati precedentemente immagazinati con addslashes la ricerca avra' buon fine?

Ovvero se il valore slashato di $search è " Pippo dell\'orto ",
La query darà esito positivo se il campo nel database è " Pippo dell'orto " ?

[dementialsite]

Se fosse come dici tu, avrai che la query SQL che sarà eseguita sarà qualcosa del genere:

SELECT *
FROM UTENTI
WHERE Nome=' Pippo dell\'orto '
                        ^--- stringa terminata! e il resto...?

Devi usare la funzione che ti ho dato due post fa per risolvere il problema:

SELECT *
FROM UTENTI
WHERE Nome=' Pippo dell''orto '
                        ^--- specificare due apostrofi significa: la stringa comprende un apostrofo

A parte questo, usando il metodo GET dovresti aver già una conversione del carattere ' in %27 (codice di escape): quindi non è questa la conversione da fare...

Stammi bene...

Strani problemi di slashes:
Il tutto funziona perfettamente su altervista e non mi funziona in locale..
Temo sia un problema di magic quotes, di come sono settati.

faccio php_info(): sul server locale i magic quotes sono off, in altervista... non si sa! php_info() in altervista manca di alcune informazioni, che vanno dal settaggio dei magic quotes ai register globals.. come mai??

Per farlo funzionare anche in locale ho risolto la questione così, se conoscete sistemi piu indicati ditemi pure!:


if (get_magic_quotes_gpc()=='0') $categ= addslashes($_GET['categ']);
else $categ= $_GET['categ'];

[Evcz]

poi su certi host c'è già attivo magic_quote, su altri no... quindi va fatto un controllo anche la per evitare di aggiungere escape doppi...

:)

comunque io userei mysql_real_escape_string()... in particolare il codice scritto in "Example 3. A "Best Practice" query" qui:
http://it2.php.net/manual/en/functio...ape-string.php

// Quote variable to make safe
function quote_smart($value)
{
   // Stripslashes
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // Quote if not integer
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
} 

poi eventualmente se non vuoi permettere tags html etc... allora metti htmlentities (http://it2.php.net/htmlentities) e compagne :)

Vi risulta che addslashes e htmlentities, se usati insieme su una stringa accentata possano creare interferenza tra loro?

In particolare mi pare di notare che se su una stringa si applica prima l'htmlentities e poi l'addslashes, l'addslashes non faccia piu il suo dovere...

// $stringa è un dato accentato proveniente da un post
$stringa= addslashes(htmlentities($stringa));

Se faccio così la query del dato accentato va a buon fine, ma se guardo nel database il dato non è stato slashato.

Se faccio invece:

$stringa= addslashes($stringa);

Il dato viene slashato, ok, ma non ho applicato l'htmlenties cosi e il dato è a rischio!

Se faccio invece:

$stringa= htmlentities($stringa);

la query INSERT, per questa stringa, nel database, non funziona, forse perche l'accento nella stringa esercita il suo disturbo nella query (significa injections a non finire no?)..

Voi cosa fareste?

P.S.: tenete presente che il sito è qui su altervista, dove i magic quotes sono gia su on! teoricamente non dovrebbe esserci nemmeno bisogno di usare addslashes o no?