Corsi on-line

PDO, parametri di input e SQL injections

Un’equivoco abbastanza diffuso vuole che PDO sia stato introdotto in PHP come semplice sostituto delle funzioni MySQL, basterebbe così utilizzare per esempio il metodo PDOStatement::rowCount al posto di mysql_num_rows() o PDO::lastInsertId in luogo di mysql_insert_id(), per abbandonare l’estensione ormai sconsigliata dal manuale ufficiale di PHP e adottare l’alternativa non discouraged.

Un punto debole di tale teoria errata sta nell’ignorare la funzione fondamentale svolta dai Prepared Statements di PDO, non tenerne conto porta a non comprendere come questi costrutti siano in grado di manipolare i dati durante l’esecuzione delle istruzioni SQL; recentemente su un forum è stata posta a questo proposito la seguente domanda:

Se un parametro proviene da un form, in PDO cosa verifica che l’input non sia vuoto o che non contenga elementi per scatenare SQL injections?

La richiesta è più che legittima, ma è condizionata dell’equivoco di cui ho parlato all’inizio dell’articolo; nell’esempio di un INSERT, i Prepared Statements di PDO entreranno in gioco appunto per “preparare” i dati all’inserimento e non per verificarli.
Quindi, prendendo il caso che un parametro di input inviato per metodo sia vuoto, se per la nostra applicazione è importante che esso sia popolato questa carattteristica dovrà essere controllata prima della query.

Per quanto concerne le SQL Injections, i Prepared Statements non le subiscono perché separano l’SQL dai dati e, se i dati non vengono manipolati come SQL sono (in linea di massima) al riparo dalle Injections.
Per essere ancora più chiari, anche nel caso in cui si voglia inserire del codice malevolo nei dati, questo non potrà essere eseguito per via del fatto che non entrerà a far parte della query SQL.
In pratica, nei Prepared Statements la parte relativa all’SQL agisce come una sorta di template che ha il compito di inviare i dati ad una tabella; quando si esegue un Prepared Statement, soltanto i dati vengono inviati e inseriti direttamente in tabella, senza formare stringhe SQL (cioè dei veicoli per le SQL Injections).

Va da se che, se non si intende sfruttare le potenzialità dei Prepared Statements, tanto vale che si adottino le classiche funzioni MySQL; queste però saranno presto considerate deprecate.

Post correlati
I più letti del mese
Tematiche