Purga stringhe PHP

[brancomat]

"lurkando" un po' su questo sito e su internet ho messo insieme queste funzioni che, nelle mie intenzioni, andrebbero usate per stampare a video informazioni prese dall'utente (tipo il nome utente e così via attinti da una sessione) o per "sanitizzare" gli input (GET e POST)

function purgastringa($i_stringa,$i_lunghezzamassima)
{
 if (!isset($i_stringa) || (trim($i_stringa)==="")) 
  return;
 if ($i_lunghezzamassima<=0)
  return;
 $i_stringa=str_ireplace('INSERT','',$i_stringa);
 $i_stringa=str_ireplace('DELETE','',$i_stringa);
 $i_stringa=str_ireplace('UPDATE','',$i_stringa);
 $i_stringa=str_ireplace('LIKE','',$i_stringa);
 $i_stringa=str_ireplace('CREATE','',$i_stringa);
 $i_stringa=str_ireplace('DROP','',$i_stringa);
 $i_stringa=str_ireplace('ALTER','',$i_stringa);
 $i_stringa=str_ireplace('GRANT','',$i_stringa);
 $i_stringa=str_ireplace('TABLE','',$i_stringa);
 $i_stringa=str_ireplace('EXISTS','',$i_stringa);
  
  
 $i_stringa = trim($i_stringa);
 
 $s = str_split($i_stringa, 1);
 $minimo=min(strlen($i_stringa),$i_lunghezzamassima);
 
 for($i=0; $i < min(strlen($i_stringa),$i_lunghezzamassima); $i++)
  if ((!ctype_alnum($s[$i])) && ($s[$i]!==' ') && ($s[$i]!=='!'))
   $s[$i]='';
    return implode(array_slice($s,0,$minimo));
}
function write($i_stringa,$i_lunghezza=30)
{
 echo purgastringa($i_stringa,$i_lunghezza);
}

In pratica il classico echo ("ciao utente".$_SESSIONE...) diventerebbe qualcosa del genere write("ciao utente ".$_SESSIONE...)

Può avere senso, o mi sto complicando la vita?
Vorrei "distruggere" tutti i possibili sql injection (in ingresso) e XSS (in uscita) ...

[.Kurt]

Può avere senso

No, nessuno.

Vorrei "distruggere" tutti i possibili sql injection (in ingresso) e XSS (in uscita) ...

Se ci fosse una magica funzione che "sanitizzasse" () tutti i tuoi input e output, utilizzeremmo tutti quanti quella. Bhè, in realtà php per qualche tempo ha avuto una opzione chiamata "magic-quotes", ormai deprecata ed eliminata, incaricata di filtrare magicamente tutti gli input, ed è stata fonte di imbarazzo per anni.

Prendi la tua purgastringa Cosa fa? Elimina qualche parola chiave di qualche linguaggio e addizionalmente togliere i caratteri non alfanumerici. Ma perché? Perché dovresti negare ai tuoi utenti la possibilità di scrivere "I like cheese!" o di scegliersi un qualsiasi nickname che contenga altri caratteri, qualche lettera accentata, una emoji, etc.?

Quindi come dovresti fare per proteggerti? E' sufficiente capire cosa si fa. Se stampi del testo in una pagina html, devi sapere che alcuni caratteri hanno un significato particolare. < e > ad esempio vengono utilizzati per dichiarare un tag (, etc.). In questo contesto, per evitare XSS, puoi convertire quei caratteri in delle entità che le rappresentano ma hanno un altro significato: http://php.net/manual/it/function.ht...alchars.phpNel contesto SQL non va bene, lì altri caratteri hanno altri significati. http://stackoverflow.com/questions/6...ction-in-phpSe devi eseguire un comando con http://php.net/manual/en/function.exec.php , e vuoi passare delle stringhe come argomenti, allora dovrai farlo in modo appropriato: http://php.net/manual/en/function.escapeshellcmd.php

E così via.

[brancomat]

No, nessuno.Sì
Prendi la tua purgastringa Cosa fa? Elimina qualche parola chiave di qualche linguaggio e addizionalmente togliere i caratteri non alfanumerici. Ma perché? Perché dovresti negare ai tuoi utenti la possibilità di scrivere "I like cheese!" o di scegliersi un qualsiasi nickname che contenga altri caratteri, qualche lettera accentata, una emoji, etc.?

Francamente di emoji, caratteri strani o inglese non è che mi interessi più di tanto.
La domanda è più modesta, ovvero
"con una funzione del genere sto sicuro sia per quanto riguarda injection che xss?"
Se la risposta è SI' allora per me va bene.
Di corsi di sicurezza PHP ne ho letti mille e sono davvero complicatissimi e difficilissimi da mettere in pratica, per una scelta che non capisco (quella di lasciar liberi di inserire qualsiasi cosa).

Forse come principiante PHP paradossalmente vedo le cose più "chiaramente".
Forse.

[k.b]

Francamente di emoji, caratteri strani o inglese non è che mi interessi più di tanto.
La domanda è più modesta, ovvero
"con una funzione del genere sto sicuro sia per quanto riguarda injection che xss?"
Se la risposta è SI' allora per me va bene.
Di corsi di sicurezza PHP ne ho letti mille e sono davvero complicatissimi e difficilissimi da mettere in pratica, per una scelta che non capisco (quella di lasciar liberi di inserire qualsiasi cosa).

Forse come principiante PHP paradossalmente vedo le cose più "chiaramente".
Forse.

Sei tu che hai chiesto "se ha senso o mi sto complicando solo la vita". La risposta e' che no, non ha senso, se poi ti va bene lo stesso e' un altro discorso.

Il motivo per cui non ha senso pero' e' piu' profondo e non riguarda sintassi o funzioni specifiche. Il punto e' che se l'utente invia dati e non comandi (cioe' NON stai riscrivendo phpmyadmin), allora bisogna trattare tutto cio' che ti invia come un dato. Per evitare SQL injections c'e' uno strumento efficace al 100% senza sbattimenti, e cioe' i prepared statements. I prepared statements consistono in parole povere nel separare query e dati, in modo che sia impossibile che i dati vadano a modificare la query stessa.

Quindi analizzare il testo di input ed eliminare manualmente cose come INSERT, DELETE, DROP eccetera, e' fatica sprecata nonche' un procedimento passibile di errore (magari ti dimentichi qualcosa), quando invece c'e' come alternativa uno strumento che risolve il problema alla perfezione.

L'unica cosa che hai come principiante e' una incorretta percezione della complessita'. Studiarti PDO e i prepared statements e' molto piu' semplice che scrivere un'assurda funzione come quella sopra, e' una soluzione infinitamente migliore, ed e' un investimento preziosissimo per la tua conoscenza.

L'errore che tutti i principianti commettono (che e' sicuramente colpa di vecchie guide obsolete scritte da altri principianti che si credevano esperti) e' quello di creare le stringhe delle query mescolandoci i dati dell'utente, esempio:

$email = $_POST['email'];
$name = $_POST['name'];
$sql = "INSERT INTO utenti (email, name) VALUES ($email, $name)"; 

il problema qui non e' non aver fatto l'escape dei valori, il problema e' che LA STRINGA DELLA QUERY NON DEVE CONTENERE DATI PASSATI DALL'UTENTE, in nessun caso e in nessuna forma.

[brancomat]

Sei tu che hai chiesto "se ha senso o mi sto complicando solo la vita". La risposta e' che no, non ha senso, se poi ti va bene lo stesso e' un altro discorso.

Il motivo per cui non ha senso pero' e' piu' profondo e non riguarda sintassi o funzioni specifiche. Il punto e' che se l'utente invia dati e non comandi (cioe' NON stai riscrivendo phpmyadmin), allora bisogna trattare tutto cio' che ti invia come un dato. Per evitare SQL injections c'e' uno strumento efficace al 100% senza sbattimenti, e cioe' i prepared statements.

Li uso da sempre, è uno dei vantaggi di partire da zero (cioè senza trascinarsi dietro codice vecchio).

Quindi analizzare il testo di input ed eliminare manualmente cose come INSERT, DELETE, DROP eccetera, e' fatica sprecata nonche' un procedimento passibile di errore (magari ti dimentichi qualcosa), quando invece c'e' come alternativa uno strumento che risolve il problema alla perfezione.

Alla perfezione non direi, perchè non comprende il problema della generazione dinamica del nome della tabella

L'unica cosa che hai come principiante e' una incorretta percezione della complessita'...

Direi il contrario, ho visto circa 4000 tipi diverse di vulnerabilità PHP, da semplici ad enormemente complesse.
Quindi se basta usare pDO e gli statement preparati allora sono già a livello avanzato

Scherzo.
Comunque per quanto riguarda XSS e cugini i metodi proposti sono talmente tanti, e talmente complessi, e insicuri (lo scrivono gli stessi autori) che "purgare" tutto mi sembra assolutamente adatto.
Meglio (per quanto mi riguarda) un sito che non accetta email del tipo @@@bvad@@°ççç\bii@qualcosa.com ma che è sicuro.

Mi sto facendo la mia piccola libreria di sanitizzazione brutale, per gli interi ad esempio oltre che per le stringhe.
Poi le userò, magari prima o poi salterà fuori qualcosa di meglio (a dir la verità su stackoverflow ho visto la codifica hex, ma non ho ancora ben riflettuto su come usarla, la utilizzo per la spedizione di nome utente e password).

La domanda resta: se taglio via tutto quello che non è alfanumerico, sia in input dall'utente, sia prima di postare sul db, non ottengo un livello di sicurezza valido, senza complicarmi la vita più di tanto?

[k.b]

Alla perfezione non direi, perchè non comprende il problema della generazione dinamica del nome della tabella

A parte il caso in cui tu ti ritrovi a scrivere un tool simile a phpmyadmin, nel 99% dei casi la necessita' di nomi dinamici delle tabelle e' un errore di progettazione. Supponendo comunque di trovarci nel 1% in cui sia una caratteristica legittima, la cosa si risolve con una semplicissima whitelist, perche' la regola e' sempre quella: nessun dato fornito dall'utente deve andare nella stringa che compone una query. Se ti attieni a questa regola, non avrai MAI problemi di SQL injection.

Meglio (per quanto mi riguarda) un sito che non accetta email del tipo @@@bvad@@°ççç\bii@qualcosa.com ma che è sicuro.

Accettare una mail di quel tipo di per se' non pone nessun problema di sicurezza, ma comunque si puo' sempre fare il controllo sulla presenza di UN UNICO carattere "@", che peraltro e' l'unico check che ha senso fare su un indirizzo email

La domanda resta: se taglio via tutto quello che non è alfanumerico, sia in input dall'utente, sia prima di postare sul db, non ottengo un livello di sicurezza valido, senza complicarmi la vita più di tanto?

Se fai questo l'unica cosa che ottieni e' dei dati corrotti rispetto all'originale, e' un po' come dire "visto che non voglio che mi rubino la macchina le do' fuoco cosi' risolvo il problema".
La cosa migliore da fare e' salvare l'input cosi' com'e', e gestirlo poi a seconda dei casi. Modificare l'input e' il peggior modo di approcciare il discorso sicurezza.

Ti faccio un esempio: stai creando un'applicazione che permette agli utenti di postare messaggi con una firma. In base alle tue regole di sicurezza, quando l'utente inserisce una firma con codice HTML tu purghi via tutto e lasci solo plain text. Un giorno decidi che vuoi dare agli utenti le firme piu' fighe e attivi l'HTML, nel frattempo pero' per quelli che l'avevano gia' messa l'HTML e' andato e non lo puoi recuperare.
Viceversa se tu ti salvi le cose come sono, hai tutti i dati nel database. Quando stampi la firma puoi tranquillamente usare strip_tags() o qualsiasi altra funzione per ottenere lo stesso risultato della tua purga, ma i dati ti rimangono dovessero mai servirti.

Stessa cosa per quello che vedo molto spesso menzionato su questo forum, e cioe' usare htmlspecialchars() o htmlentities() come forma di escaping o perche' non sanno gestire le vocali accentate. E' una cosa estremamente stupida, intanto perche' quelle funzioni NON SONO funzioni di escaping ne' alternative a utf8 ma hanno uno scopo ben preciso, e poi perche' se quei dati li vuoi usare al di fuori di una pagina HTML (in una newsletter, in un file di log, etc) tutti i codici HTML non hanno alcun senso e non fanno altro che corrompere i dati.

[MiWebDesign]

Ciao brancomat,

sinceramente secondo me non ha senso creare queste funzioni self-made, ormai con le versioni di PHP che ci sono hai già tutto pronto.

Per esempio puoi usare la funzione filter di PHP5 e gli passi il tipo di filtro da applicare, ed è nativo

[brancomat]

Ciao brancomat,

sinceramente secondo me non ha senso creare queste funzioni self-made

e perchè mai? non è che la libreria PHP abbia chissà quali capacità voodoo, intendo rispetto a un programma qualsiasi

[.Kurt]

Per esempio puoi usare la funzione filter di PHP5 e gli passi il tipo di filtro da applicare, ed è nativo

Sconsiglio di usare filter. Dovresti fare l'escape dei caratteri. Sono due cose molto diverse: con la prima rimuovi certe parti della stringa, le modifichi secondo qualche regola o la validi secondo alcuni formati, con la seconda fai in modo che certi caratteri speciali non vengano interpretati diversamente da come vorresti.

Se, aggiornando il campo email della vostra tabella utenti, pensate che per prevenire sql injection sia sufficiente controllare (con filter_var) che il valore dato dall'utente sia una email valida, allora vi meritate l'injection.

[MiWebDesign]

Sconsiglio di usare filter. Dovresti fare l'escape dei caratteri. Sono due cose molto diverse: con la prima rimuovi certe parti della stringa, le modifichi secondo qualche regola o la validi secondo alcuni formati, con la seconda fai in modo che certi caratteri speciali non vengano interpretati diversamente da come vorresti.

Sorry Kurt ma non sono d'accordo, specie sul "Dovresti fare l'escape dei caratteri" come se filter_var non lo facesse.

Ecco cosa fa filter_var: http://www.w3schools.com/php/filter_sanitize_string.asp

O sono tonto io o quello che vedo è proprio l'escape dei caratteri/tag HTML, correggimi se sbaglio.

Se, aggiornando il campo email della vostra tabella utenti, pensate che per prevenire sql injection sia sufficiente controllare (con filter_var) che il valore dato dall'utente sia una email valida, allora vi meritate l'injection.

A dirla tutto per verificare il campo email basta verificare l'esistenza MX DNS (cosa di due righe in PHP) così sei sicuro che non ti basta inserire: cacca@cacca.it per superare il controllo, quindi lasciamo stare escape e check caratteri ti basta mettere quella condizione.