SQL Injection solutions [closed]

Prima di tutto, non dovresti ruotare il tuo filtro SQL Injection. L'idea di fare ciò è stata ampiamente discussa nella comunità della sicurezza e il consenso è che non è quasi mai una buona idea.

My question is all we actually have to filter is the input the user/attacker tries to input in the userID field right?

Non proprio (ma forse).

Perché forse? Perché idealmente le password vengono sottoposte a hash / salted prima di essere memorizzate nel database. Ciò significa che quando un utente tenta di accedere, la password fornita deve essere sottoposta a hash / salted prima di essere confrontata con ciò che si trova nel database. Se ciò è fatto, non penso che SQL Injection sarebbe possibile attraverso il campo della password perché il valore immesso per la password sembrerebbe completamente diverso dal momento in cui è arrivato al database.

Questo è stato molto, quindi lasciatemi dare un esempio rapido che, si spera, aiuterà a chiarire. In un sistema che non ha password hash / sale, è possibile passare quanto segue per utente / password: abe / ' OR '1'='1

E la query che verrebbe eseguita sarebbe:

SELECT * FROM USERS WHERE name = 'abe' AND password = '' OR '1'='1'

Ma se la password è salata / hash, la query generata per gli stessi valori sarà simile a questa:

SELECT * FROM USERS WHERE name = 'abe' AND password = '1e54e11980633c7d1fb8a6be99e3e294'

Si può vedere che nel secondo esempio l'SQL iniettato diventa hash e quindi inutilizzabile per SQLi.

Anche se è teoricamente possibile che il tuo codice non sia vulnerabile a SQL Injection, contare sullo scenario che ho descritto sopra per proteggerti sarebbe il modo sbagliato di avvicinarti alla sicurezza della tua applicazione . Quando si ha a che fare con SQL Injection dovresti semplicemente proteggere tutti gli input e non contare su nessun'altra cosa che ti protegga.

Per proteggere adeguatamente la tua applicazione da SQL Injection, dovrai utilizzare query parametrizzate / istruzioni preparate. OWASP ha un buon articolo introduttivo su qui . I dettagli esatti su come dovresti implementarlo dipendono dalla lingua che stai utilizzando.

Onestamente, sono un po 'preoccupato per il fatto che il tuo professore ti abbia mandato sulla traccia del filtro. Per qualcuno che sta appena iniziando con la sicurezza, la prima cosa che dovresti imparare sono le query parametrizzate.

No, ti manca qualcosa. L'iniezione SQL può essere eseguita su qualsiasi campo che un utente possa eventualmente modificare. Questo include non solo il tuo nome utente e il tuo campo password, ma anche eventuali campi nascosti che possono essere memorizzati sul sito Web e trasferiti al server (in quanto l'utente può alterare il loro contenuto della pagina web).

Se il valore proviene dal computer dell'utente in qualsiasi modo, deve essere filtrato prima di utilizzarlo in un'istruzione SQL per impedire l'iniezione SQL mediante il filtro. Ci sono un sacco di regole e trucchi diversi che possono aggirare i filtri semplici, quindi un filtro sicuro completo è una cosa complicata da fare.

La soluzione migliore è utilizzare il cosiddetto SQL parametrico che indica a SQL che il valore di ogni parametro è un valore e non un codice di query. Basta evitare di utilizzare l'input dell'utente in una query SQL, se possibile.

Non sono sicuro di averlo capito correttamente ma ecco cosa penso.

Finché utilizzi le query con parametri, dovresti essere sicuro nel tuo caso. Evita di fare affidamento esclusivamente sui filtri in quanto questi possono essere aggirati. Ma se hai intenzione di usare i filtri, il carattere speciale che stai permettendo provocherà anche dei limiti di filtraggio. In questo caso è possibile filtrare i nomi utente e salvare l'hash della password nel database e confrontare gli hash dal database per evitare l'iniezione. In questo modo si possono avere meno limitazioni quando si utilizza il filtro se implementato correttamente. Cerca di non scrivere usando i tuoi filtri della lista nera per la prevenzione di SQL injection. Ci sono già delle librerie per questo. Li potete trovare sul link sottostante insieme alla documentazione dettagliata su questo argomento. Ma in generale cerca di utilizzare le query con parametri, laddove possibile, evita di costruire query dinamiche con input forniti dall'utente e utilizza le librerie di escape standard.

Per informazioni molto dettagliate su questo argomento puoi fare riferimento a: link