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:
Copia codice 

<?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:

Copia codice 

<?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.