Non è necessario usare più le variabili $_GET o $_POST. In realtà, probabilmente non si dovrebbe usare più $_GET e $_POST. A partire della versione PHP 5.2, c’è un modo nuovo e migliore per recuperare in modo sicuro dati inviati dall’utente.

Analisi

Quante volte abbiamo sentito parlare dei problemi di sicurezza nelle applicazioni PHP derivanti da parametri GET e POST senza caratteri di escape? L’uso corretto dei caratteri di escape è un problema perenne per lo sviluppo del web in generale, e per alcuna ragione PHP sembra avere avuto la sua parte per la cattiva pubblicità su questo fronte.
Sul lato del database, molte preoccupazioni sull’SQL injection ci hanno soffocato. Gli lucidi sviluppatori della PDO, per esempio, hanno costruito una libreria che analizza i dati e i caratteri di escape in modo appropriato. Ma il problema di convalida dell’input e la sua sanificazione è ancora un problema sostanziale. Con mia sorpresa, molti sviluppatori PHP trascorrono ancora del tempo prezioso per lo sviluppo del codice personalizzato da usare per filtrare d’input.
Perché questo è sorprendente? Perché PHP (dalla versione 5,2 in poi) è dotato di un sistema di filtraggio che rende i compiti di validazione e i dati per la sua sanificazione banalmente semplice. Piuttosto che accedere alle superglobals $_POST e $_GET direttamente, è possibile utilizzare le funzioni di ancora come filter_input() e filter_input_array(). Diamo un rapido sguardo a un esempio:
<?php
$mia_stringa = filter_input (INPUT_GET, 'mia_stringa', FILTER_SANITIZE_STRING);
?>
Il codice di sopra è in grosso modo l’equivalente di recuperare $_GET['mia_stringa'] per poi analizzarlo attraverso una sorta di filtro che mette a nudo i caratteri HTML indesiderabili e altri. Questo rappresenta sanificazione dei dati, una delle due cose che il sistema di filtraggio può fare. I due compiti del sistema di filtraggio sono:

  • Validazione: Fare in modo che i dati forniti è conforme alle aspettative specifiche. In questa modalità, il sistema di filtraggio indicherà (con un booleano) se i dati soddisfano il criterio.
  • Sanificazione: Rimozione dati indesiderati dal ingresso input dell’utente e di effettuare qualsiasi tipo di coercizione necessaria. In questa modalità il sistema di filtraggio restituisce i dati sterilizzati.

Per impostazione predefinita, il sistema di filtraggio fornisce un serraglio di filtri che vanno dalla validazione e sanificazione dei tipi di base (booleani, interi, float, ecc) ai filtri avanzati, che permettono l’uso di espressioni regolari o retrochiamate personalizzate.
L’utilità di questa libreria dovrebbe essere ovvia. Sono finiti i giorni quando si processavano i nostri input con i propri strumenti di controllo. Adesso possiamo usare uno standard (e con migliori prestazioni) integrato nel sistema.
Ma vorrei andare un passo avanti anziché presentare questo semplicemente come opzione. Mi spingerei fino a dire che non ci si deve più accedere direttamente ai superglobals contenente l’input dell’utente. Semplicemente non c’è ragione per farlo. Nella miriade di problemi di sicurezza legati al mancato ingresso del filtro c’è più di una giustificazione sufficiente per la mia affermazione. Utilizzare sempre il sistema di filtraggio. Renderlo obbligatorio.
“Ma”, si potrebbe obiettare, “se io non voglio i miei dati filtrati?” Il sistema di filtraggio fornisce un filtro nullo (FILTER_UNSAFE_RAW), per i casi in cui i dati non si vuole o non devono essere filtrati (e questi casi sono rari) e si dovrebbe usare qualcosa come questo che segue:

<?php
$dati_non_filtrati = filter_input(FILTER_GET, 'dati_non_filtrati', FILTER_UNSAFE_RAW);
?>
Io non consiglio questo per follia o fanatismo. C’è un vantaggio seguendo questo modello: posso molto rapidamente scoprire tutte le variabili non filtrate nel mio codice eseguendo una semplice operazione di ricerca per la costante FILTER_UNSAFE_RAW. Questo è molto più facile per rilevare mediante chiamate a $_GET e trovare tutti quelli che non sono stati correttamente convalidati o sanificati. Il trattamento del rischio d’ingresso può essere gestito in modo più efficiente seguendo questo schema.
I filtri non risolveranno mai tutti i problemi legati alla sicurezza, ma sono un enorme passo nella giusta direzione quando si tratta di scrivere del codice con sicurezza, rendendolo performante. È anche più semplice. Certo, le chiamate lle funzioni è più lungo, ma allevia gli sviluppatori della necessità di scrivere i propri sistemi di filtraggio. Questi sono le maledettamente buone ragioni per non usare mai $_GET (o $_POST e gli altri) di nuovo.

Note
Articolo tradotto de me dal post di Matt Butcher su php architect con il titolo Never Use $_GET Again.
Similari
Elencare file e directory con PHP
8% Php
Questo articolo illustra un usuale compito che si potrebbe avere sperimentato durante lo sviluppo di un’applicazione in PHP: elenchi di file e directory. Si occupa di diverse soluzioni di base e avanzate, ciascuno con i su…
Come rimuovere i caratteri No ASCII da una stringa
8% Php
In un lavoro che sto’ facendo, un cliente mi fornisce i suoi aggiornamenti attraverso un file in formato csv estratto dall’applicazione Excel della Microsoft. Ora ottenere i dati che servono da questo file prodotto da M$ n…
JavaScript Snippets
7% JScript
Vorrei postare un paio di frammenti di codice che ho in giro qui da un po’. Forse gli intenditori sbadiglieranno, ma ci sono un sacco di persone che sono alla ricerca di queste minuzie. Mi sbarazzo di questi appunti che ho…
Comprendere meglio Random
6% Php
I valori casuali sono cruciali nella programmazione per lo sviluppo di sistemi sicuri che non sono vulnerabili a dannose sovversioni. La crittografia, per esempio, si basa su valori di generazione casuali e la loro riprodu…
Hashing delle password in PHP
6% Php
Molte delle moderne applicazioni in PHP accedono a informazioni importanti dell’utente e le memorizzano in un database. Ad esempio, una web app potrebbe avere un sistema di registrazione per i nuovi utenti. Ma come si dovr…