Prevenzione dell'iniezione SQL - perché si dovrebbe sfuggire all'input se si utilizzano istruzioni preparate?

Question

Sto facendo alcune ricerche nel campo della sicurezza Web, e il revisore del mio articolo ha detto:

"Dovrebbe essere chiaro che per evitare SQL Injection, l'applicazione deve utilizzare le istruzioni preparate, stored procedure e la fuga di ingresso"

La mia domanda è: uno di questi metodi non è sufficiente? Ok, le istruzioni preparate o le stored procedure sono migliori di una semplice escape, ma se uso PDO, perché dovrei sfuggire all'input o avere una stored procedure? Ha senso ciò?

Answer 1

vorrei cambiare la formulazione del revisore a:

Dovrebbe essere chiaro che per evitare SQL Injection, l'applicazione deve utilizzare le istruzioni preparate, fuga di ingresso, o l'applicazione del filtro dati prima di interpolazione in una stringa SQL.

Non è necessario uscire da un valore se si vuole passare come parametro. In realtà, non dovresti, perché inserirai letteralmente barre retroverse nei tuoi dati.

È necessario interpolare stringhe nell'istruzione SQL quando non è possibile utilizzare un parametro di query. Gli esempi includono: i nomi

• tavolo e nomi di colonna, che hanno la loro own syntax for delimited identifiers. Questi devono essere parte della query SQL al momento della preparazione, quindi l'RDBMS può analizzarli e convalidarli.

• Parole chiave SQL, che devono essere disinfettate ma non possono essere sfuggite perché non sono delimitate.

• Altre sintassi o espressioni.

• Alcuni casi in cui è necessario fornire valori letterali al momento della preparazione, ad es. Le funzioni fulltext di MySQL non supportano i parametri per il modello di ricerca.

Le procedure memorizzate non sono una difesa contro l'iniezione SQL. È possibile preparare ed eseguire istruzioni SQL dinamiche insicure all'interno di una stored procedure. Vedi http://thedailywtf.com/Articles/For-the-Ease-of-Maintenance.aspx per una grande storia a riguardo.

Coprisco tutti questi casi nella mia presentazione SQL Injection Myths and Fallacies. Potrebbe essere una risorsa utile per te.

Coprendo anche la difesa di SQL injection in un capitolo del mio libro, SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

Answer 2

Se uso PDO, perché dovrei scappare l'input o avere una stored procedure?

Finché si sempre uso DOP, non vedo un motivo per preoccuparsi di fuga o di SP di ingresso.

Answer 3

In caso di dubbio, chiedetevi: questo pezzo di dati di input semplici sarà evaso da alcune API lungo la linea? La maggior parte delle volte lo faranno, tranne quando costruisci manualmente le frasi SQL dai dati di input.

Non si deve scappare se si utilizza PDO. Non si deve scappare se si utilizzano le istruzioni preparate JDBC con i parametri. Allo stesso modo, la maggior parte delle altre API si occupa anche di questo. Le stored procedure non sono nemmeno interessate ai dati di escape e il loro utilizzo non eviterà magicamente problemi di sicurezza di SQL injection se i dati di input non sono sfuggiti nell'SQL che esegue la procedura.

Dati SQL-Escape sempre inseriti in frasi SQL. Mai SQL-Escape dati al di fuori delle frasi SQL.