Domande, forse banali, sulle entità nel database

[Ferie]

Dopo una ricerca ancora non ho una risposta definitiva ad alcuni miei dubbi riguardanti il giusto procedimento per interagire con le entità su database.

1) Nel senso, se io uso trim(htmlentities($_REQUEST[$variabile])) per una variabile $variabile che mi arriva ad esempio da un form, è sufficiente?
E soprattutto, risulta sicura per la protezione del database?

2) Nel richiamare i dati dal database, nel caso in cui debba ricevere come ritorno dei dati che includono tag HTML (in sostanza per fare il processo inverso rispetto al precedente), e quindi per decodificare i dati è sufficiente html_entity_decode()?

3) Se ad esempio utilizzo addslashes() al posto di htmlentities() ho dei vantaggi solo lato database, perchè questo mette in sicurezza apici e doppie virgole quindi non mi dà vantaggi sotto il punto di vista di codifica/decodifica, giusto?
Allora perchè e in quali casi possono servire le funzioni addslashes() e mysqli_real_escape_string() se io utilizzo sempre htmlentities()?
Su una guida qui su HTML.it viene addirittura utilizzata filter_var($_POST[$variabile], FILTER_SANITIZE_STRING) che vantaggi può dare rispetto alle altre?

4) E poi ancora, da manuale PHP, htmlspecialchars() non include tutti i tag HTML, quindi non ritengo possa essere proprio utile, e dunque, quando può servire?
In quali casi viene utilizzata?

[codencode]

A mio avviso il modo giusto di procedere è il seguente:
utilizzare la funzione mysqli_real_escape_string() che è la funzione apposita per eseguire l'escape delle stringhe per l'inserimento nel db. Le altre funzioni (es htmlentities() o addslashes()) non servono, almeno in questo caso.
htmlspecialchars() è utile per chi utilizza la codifica utf8 e quindi deve poter stampare stringhe provenienti da un db senza problemi, infatti tale funzione sostituisce i caratteri speciali e cioè ',", &, <, > nelle corrispondenti entità in modo che il browser non faccia confusione con gli stessi caratteri utilizzati per scrivere i tag html che formano la struttura di un documento web.
htmlentities() è utile invece per chi non utilizza la codifica utf8 ed ha quindi l'esigenza di dover convertire anche i caratteri accentati.
Ovviamente le funzioni htmlspecialchars() e htmlentities() necessitano del parametro ENT_COMPAT che indica il comportamento relativo agli apici. Comunque per ulteriori dettagli vedere la guida:
http://php.net/manual/en/function.htmlspecialchars.php
http://php.net/manual/it/function.htmlentities.php

[Ferie]

Bene, grazie intanto per la risposta, quindi la cosa migliore per inserire i dati in sicurezza è fare una cosa del genere:

trim(mysqli_real_escape_string($_REQUEST[$variabile])) 

o forse non serve nemmeno la trim() a questo punto?

E se poi i dati che io voglio estrarre dal database contengono dei tag (cioè fare il processo inverso, farmi restituire i caratteri speciali per i quali la real escape mi ha fatto l'escape) che funzione uso?

Non riesco a trovare un decodificatore nel manuale se non quello per htmlentities() (che dovrebbe essere html_entity_decode() ) e quello per addslashes() (che invece è stripslashes() ).

Nella risposta, dici che addslashes() non serve in questo caso (quello del dato passato dal form?), quindi in quali altri casi si usa?

E per quanto riguarda filter_var($_POST[$variabile], FILTER_SANITIZE_STRING) che vantaggi può dare rispetto alle altre e in quali casi usare quest'ultima?

[codencode]

trim() serve per rimuovere gli spazi all'inizio e alla fine di una stringa, quindi può essere utile in caso di username o password.
Per quanto riguarda la funzione mysqli_real_escape_string(), forse non hai capito cosa fa di preciso, questa esegue l'escape degli apici quindi se hai una query tipo:

$sql="INSERT INTO nome_tabella values('$variabile') 

supponendo che $variabile assuma come valore: ciao questo è il valore '
quando viene passato il valore alla variabile, la stringa sql diventa:
"INSERT INTO nome_tabella values('ciao questo è il valore'')"
quindi la stringa viene chiusa male e di conseguenza c'è la possibilità che venga fuori un errore e quindi il tuo sistema può essere soggetto ad attacchi di tipo sql injection.
Invece utilizzando la funzione mysqli_real_escape_string() e cioè

$variabile = mysqli_real_escape_string($variabile); 

il valore che assumerà la variabile sarà: ciao questo è il valore \' quindi è stato inserito il carattere \ prima dell'apice e questo permette il corretto funzionamento perchè la string anon verrà chiusa in modo inatteso.
Quindi ciò significa che quando riprendi il valore dal db, non c'è bisogno di chiamare funzioni sul valore, come ad esempio avviene per htmlentities().
addslashes() lo puoi utilizzare per eseguire l'escape degli apici su valori che non andranno a finire in un db.
filter_var() non conosco molto bene perchè non ne ho avuto mai la necessità, ma in teoria serve per applicare dei filtri ad una variabile sempre a livello di validazione e quindi serve per testare il tipo di dato.

[Ferie]

Quindi mi stati dicendo che per la sicurezza del database non importa se un utente può scrivere nel db caratteri come > oppure < o ancora cose come queste != oppure == od ancora i punti e virgola o gli slash e backslash?
Perchè come tu stesso dici, la mysqli_real_escape_string fa' l'escape solo degli apici e dei doppi apici, e poi, leggo, anche i caratteri di fine riga e del null.

Ad ogni modo non ho ancora capito come faccio poi a richiamare dal db i dati senza gli escape di mysqli_real_escape_string ? Uso sempre stripslashes()?

E ancora non ho capito come fare se io ad esempio volessi memorizzare nel database questa cosa qui:

"<span style="font-style: italic;">Hello Dolly</span>" & egrave; un plug-in gratuito per <span style="font-style: italic;">WordPress</span>

mysqli_real_escape_string mi fa l'escape, in questo caso di tutti gli apici e delle virgolette (lascia stare che l'entità è scritta male, il forum qui non me la prende come dico io...).
Però nel db, ad esempio, il carattere accentato mi viene visualizzato come è però io vorrei che mi fosse memorizzato come & egrave; di modo che una volta che vado a richiamare il record mi ritorni & egrave; e non è.

A tal proposito è corretto fare una cosa di questo tipo:

$nuova_var = trim(mysqli_real_escape_string(htmlentities($_REQUEST[$variabile]))) 

[codencode]

Ad ogni modo non ho ancora capito come faccio poi a richiamare dal db i dati senza gli escape di mysqli_real_escape_string ? Uso sempre stripslashes()?

Quando vai a riprendere i dati dal db non devi utilizzare nessuna funzione, non è come utilizzare htmlentities() per la conversione e html_entity_decode() per riottenere la string aoriginaria. mysqli_real_escape_string() esegui l'escape, fare l'escape significa anteporre agli apici il carattere backslash, e questo serve semplicemente per far funzionare le query, non è che viene inserito nel db il carattere backslash. E' chiaro?

Però nel db, ad esempio, il carattere accentato mi viene visualizzato come è però io vorrei che mi fosse memorizzato come & egrave; di modo che una volta che vado a richiamare il record mi ritorni & egrave; e non è.

Molto probabilmente visualizzi il db con phpmyadmin e quindi interpreta le entità convertendole in caratteri accentati. Ma in realtà sono sotto forma ti entità.
Anche se a mio avviso sarebbe più opportuno memorizzarlo come carattere accentato, ma questo è solo un mio parere.

[Ferie]

In realtà quando vado a riprendere la riga di cui scrivevo in precedenza con l'entità & egrave; a me serve che venga visualizzata in uscita come dovrebbe essere stata memorizzata perchè dalla nuova posizione la devo modificare e risalvare (fare un update in sostanza).
Spiego meglio: c'è un form che inserisce la fantomatica frase nel db.
In un'altro momento e in un'altro form, posso modificare la frase: quindi questo form viene precompilato con la frase attualmente presente nel db (una semplice select in sostanza); se viene premuto il tasto di aggiornamento delle modifiche, viene effettuato l'update sul db.

Ora, se il form viene precompilato con i caratteri accentati e viene fatto l'aggiornamento, mi ritorna un errore in cui mi dice che non è stato possibile aggiornare il db: forse è un problema di charset del db?

Ad ogni modo mi domandavo se utilizzare prima di mysqli_real_escape_string() la htmlentities() potesse risolvere il problema, cioè fare una cosa di questo tipo:

mysqli_real_escape_string(htmlentities($_REQUEST[$variabile])) 

ma ancora non ho avuto modo di provare...

[codencode]

Ora, se il form viene precompilato con i caratteri accentati e viene fatto l'aggiornamento, mi ritorna un errore in cui mi dice che non è stato possibile aggiornare il db: forse è un problema di charset del db?

Che tipo di errore ti da?

[Ferie]

In realtà al momento è solo un semplice:

Bad Request

Your browser sent a request that this server could not understand.

e me lo dà sempre quando invio caratteri accentati, se invece invio le entità, ciò non avviene.
Quindi torno alla domanda: forse è un problema di charset della tabella nel db?

Se utilizzo prima di mysqli_real_escape_string() la htmlentities() secondo te, risolvo il problema?

mysqli_real_escape_string(htmlentities($_REQUEST[$variabile])) 

[codencode]

Che charset utilizzi?
A volte questo problema si verifica a causa dei cookie, prova a svuotarli o prova a cambiare browser e vedi cosa succede.