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
Python per tutti
136% Python
Python para todos è un libro sulla programmazione in Python. Questo è un tutoriale su Python adatto a tutti i livelli e si può scaricare in pdf gratuitamente in spagnolo. Il tutoriale di Python…
Guida allo Zend Framework
68% Zend
Zend Framework è un framework open source per PHP. Zend Framework separa la logica e le azioni usando il pattern MVC (Model View Controller). Cosa è lo Zend Framework? Framework per la costruzione di siti web più veloci e …
Fondamentali di jQuery
65% JQuery
jQuery stà diventando rapidamente uno strumento che ogni sviluppatore web di interfacce dovrebbe conoscere. Lo scopo di questo libro è di fornire una panoramica della biblioteca, in modo che qu…
Elencare file e directory con PHP
52% 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…
Hashing delle password in PHP
22% 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…