Htmlencoding è una soluzione adeguata per evitare attacchi di SQL injection?

Question

Ho sentito dire che la soluzione più semplice per prevenire attacchi di SQL injection è codificare in html tutto il testo prima di inserirlo nel database. Quindi, ovviamente, decodifica tutto il testo durante l'estrazione. L'idea è che se il testo contiene solo e commerciale, punto e virgola e caratteri alfanumerici, non puoi fare nulla di malevolo.

Mentre vedo una serie di casi in cui questo può sembrare a lavorare, prevedo i seguenti problemi nell'utilizzo di questo approccio:

• Sostiene di essere una pallottola d'argento. Potenzialmente impedire agli utenti di questa tecnica di comprendere tutti i possibili problemi correlati, come gli attacchi di secondo ordine.
• Non impedisce necessariamente attacchi di carico utile di secondo ordine/ritardato.
• Sta usando uno strumento per uno scopo diverso da quello per cui è stato progettato. Ciò potrebbe causare confusione tra i futuri utenti/sviluppatori/manutentori del codice. È anche probabile che sia ben lontano dall'ottimizzazione delle prestazioni.
• Aggiunge un potenziale calo di prestazioni a ogni lettura e scrittura del database.
• Rende i dati più difficili da leggere direttamente dal database.
• Aumenta la dimensione dei dati sul disco. (Ogni carattere ora è di ~ 5 caratteri - A sua volta questo può anche influire sui requisiti di spazio su disco, paging dei dati, dimensioni degli indici e prestazioni degli indici e altro ancora?)
• Ci sono potenziali problemi con i caratteri unicode ad alta gamma e la combinazione di caratteri?
• Alcune routine/librerie di codice html [en | de] si comportano in modo leggermente diverso (ad esempio alcuni codificano un apostrofo e altri no. Possono esserci più differenze.) Quindi lega i dati al codice utilizzato per leggere & scrivilo . Se si utilizza codice che [en | de] codifica diversamente, i dati potrebbero essere modificati/corrotti.
• È potenzialmente più difficile lavorare con (o almeno eseguire il debug) qualsiasi testo già codificato in modo simile.

C'è qualcosa che mi manca?
Si tratta di un approccio ragionevole al problema della prevenzione degli attacchi SQL injection?
Ci sono dei problemi fondamentali nel cercare di prevenire gli attacchi per iniezione in questo modo?

Answer 1

È necessario impedire SQL injection utilizzando i collegamenti dei parametri (ad esempio, non concatenare mai le stringhe SQL con input dell'utente, ma utilizzare segnaposto per i parametri e lasciare che il framework che si utilizza esegua correttamente l'escape). La codifica Html, d'altra parte, dovrebbe essere utilizzata per prevenire lo scripting cross-site.

Answer 2

Come si ottiene l'idea che il testo con codifica HTML contenga solo e commerciale, punto e virgola e alfanumerici dopo la decodifica?

Posso davvero codificare un "" in HTML, e questa è una delle cose necessarie per metterti nei guai (dato che è un delimitatore di stringhe in SQL).

Quindi, funziona SOLO se si inserisce il testo codificato HTML nel database.

ALLORA avete problemi con qualsiasi ricerca di testo ... e presentazione di testo leggibile all'esterno (come in SQL manager). Considererei una sitaution davvero pessima, dal momento che non hai risolto il problema, solo un nastro adesivo di un evidente vettore di attacco.

I campi numerici sono ancora problematici, a meno che la gestione dell'HTML sia perfetta, cosa che non assumerei considerando questa soluzione alternativa.

parametri

Use SQL;)

Answer 3

Il singolo carattere che consente l'iniezione SQL è la stringa SQL Disincrostante ', noto anche come esadecimale o decimale 27 39.

Questo carattere è rappresentato nello stesso modo in SQL e in HTML. Quindi una codifica HTML non ha alcun effetto sugli attacchi di SQL injection.

Answer 4

Assolutamente no.

Le iniezioni SQL devono essere prevenute mediante query parametrizzate. O nel peggiore dei casi sfuggendo il parametro SQL per SQL, non HTML. Ogni database ha le sue regole su questo, l'API mysql (e la maggior parte dei framework), ad esempio, fornisce una funzione specifica per questo. I dati stessi nel database non dovrebbero essere modificati se memorizzati.

L'escape di entità HTML impedisce XSS e altri attacchi durante la restituzione del contenuto Web ai browser dei clienti.