caratteri speciali

[M4rko]

[supersaibal]Originariamente inviato da Fabio Heller
Conviene farlo nel momento in cui si salvano i dati nel db? Io direi di sì, per non doverlo fare ogni volta che estrai e visualizzi i dati. [/supersaibal]

Ehi, per una volta non sono d'accordo con Fabio

Le motivazioni sono queste:
filtrare gli input e filtrare gli output sono due operazioni ugualmente importanti, ma che stanno su livelli diversi.

Preparare un testo per essere presentato in output su una pagina web (leggi: usare htmlentities() ad esempio) già prima dell'inserimento nel database secondo me è scorretto perchè vincola il testo memorizzato a quel singolo utilizzo. Se lo stesso testo memorizzato dovesse essere mandato in output su shell, o se dovesse essere spedito via mail, in formato testo naturalmente, o se dovesse essere esportato in .csv, o semplicemente se dovesse essere modificato tramite un form, bisognerebbe ogni volta ri-elaborare il testo per riportarlo alla forma originale (leggi: usare html_entity_decode() che fa il contrario di htmlentities).

Ora.. siamo d'accordo che il più delle volte quello che ci interessa è l'output su una pagina web, però filtrare input e output nello stesso momento mi pare un esempio di "cattivo design" (passatemi il termine). Non so se mi sono spiegato

[mircov]

Si ti sei spiegato perfettamente e sono anche io d'accordo con te. Però a questo punto si dovrebbe fare una considerazione:

il testo verrà usato di più su una pagina web o su un altro "supporto"?

Se decidi che il tuo testo sarà spedito prettamente via e-mail allora non lo trasformi ma se invece il tuo testo dovrà essere letto più volte su una pagina web e solo opzionalmente su una e-mail bhe, allora...

[M4rko]

[supersaibal]Originariamente inviato da mircov
Si ti sei spiegato perfettamente e sono anche io d'accordo con te. Però a questo punto si dovrebbe fare una considerazione:

il testo verrà usato di più su una pagina web o su un altro "supporto"?

Se decidi che il tuo testo sarà spedito prettamente via e-mail allora non lo trasformi ma se invece il tuo testo dovrà essere letto più volte su una pagina web e solo opzionalmente su una e-mail bhe, allora... [/supersaibal]

E' una considerazione che va fatta, e nella pratica magari le mie sono solo pippe inutili.

Diciamo (sulla base di esperienze di vita vissuta ) che quello che oggi viene utilizzato in un unico modo, domani potrebbe essere utilizzato anche in un altro, per cui tanto vale progettare l'applicazione nel modo più pulito possibile.
Non so, forse quella che ho sollevato è una questione meno importante, quello che conta è la consapevolezza di dover filtrare input e output, poi sul dove e sul come si può discutere..

[mircov]

Anche questo è vero!

[Fabio Heller]

[supersaibal]Originariamente inviato da M4rko
Ehi, per una volta non sono d'accordo con Fabio

Le motivazioni sono queste:
filtrare gli input e filtrare gli output sono due operazioni ugualmente importanti, ma che stanno su livelli diversi.

[/supersaibal]

Ciao Marco,
potrei essere d'accordo ma nel 90% dei casi l'unica cosa diversa che mi capita, rispetto a usare quel output in una pagina HTML, è usare lo stesso output per interagire con Flash. E anche in questo caso la soluzione descritta non crea problemi comunque.

A livello teorico è giusto ragionare come ragioni tu, a livello pratico, salvo esigenze molto particolari, meglio risparmiare risorse facendo una volta per tutte quello che altrimenti dovrei fare ad ogni output.

Se lo stesso testo memorizzato dovesse essere mandato in output su shell, o se dovesse essere spedito via mail, in formato testo naturalmente, o se dovesse essere esportato in .csv, o semplicemente se dovesse essere modificato tramite un form, bisognerebbe ogni volta ri-elaborare il testo per riportarlo alla forma originale (leggi: usare html_entity_decode() che fa il contrario di htmlentities).

Visto che l'output per l'HMTL è la regola e le altre sono eccezioni...a questo punto meglio fare il parsing dei contenuti (e riconvertire le entità) solo quando si verificano le eccezioni.

Una soluzione che salverebbe capre e cavoli sarebbe quella di adottare un sistema di caching dell'output, ma questo sta alla pignoleria del programmatore.


X Mirco

Non ha senso passare fare

htmlspecialchars (, ; _)

Non devi confondere ciò che riguarda le sql injections con ciò che riguarda l'inquinamento dell'output html (ad es. con javascript)

I caratteri , ; _ sono pericolosi per l'SQL e devi usare quanto ti ho detto fino ad ora (mysql_real_escape_string, str_replace etc.etc.) mentre htmlspecialchars htmlentities() etc.etc. vanno applicati i un momento successivo.

Prima "depuri" per l'sql e poi depuri l'html.
In teoria, anche senza usare htmlentities potresti utilizzare un preg_replace con espressione regolare che elimini solo javascript, attributi src che richiamino immagini esterne , e altri riferimenti a risorse esterne.

[mircov]

Si, infatti. Me ne sono accorto mentre buttavo giù un ragionamento su carta mi sono accprto che stavo mischiando le due cose.

Hai accennato prima ad una depurazione dell'input (src, javascript): quali altri tipi di cose dovrei evitare che vengano inserite?