La frase SQL ha questo aspetto,
"SELECT * from XX where id = '" + id + "'"
La variabile id proviene direttamente dal parametro GET denominato id .
E l'app Web Java non consentiva esplicitamente la virgoletta singola. Se in quel parametro è stata trovata una singola quota, il server interrompe immediatamente l'elaborazione e restituisce un errore.
Quindi, è ancora sfruttabile? Con ambiente postgresql e tomcat.
Potresti dare un'occhiata a questo documento ( link della macchinabackback ). Descrive alcuni metodi per aggirare tali filtri.
Ad esempio, alcuni filtri SQL sostituiscono tutte le virgolette singole con una coppia di virgolette singole. Tuttavia, inserirli con un input contenente \' può ignorarlo.
Inoltre, c'è contrabbando Unicode, in cui si utilizza un carattere Unicode che Java (PHP / Ruby / Python / qualunque) comprende come diverso da una citazione, ma il database non lo fa.
A meno che tu non abbia una ragione davvero buona, ti consiglio di usare l'escape incorporato.
Stai parlando di "prevenire il male conosciuto" che funziona solo fino a quando qualcuno non pensa a una nuova cosa negativa. Come dice @Manishearth, \' è una tecnica. Per un URL, %27 è un altro. In HTML, puoi avere ' , ' , ' , ' , ' sono altri. Che cosa fa il tuo server se queste tecniche sono combinate come in, %40%230039%3B ( ' url encoded) o %5C%27 ( \' url encoded) o \\' ?
Prevenire il male noto è sempre una proposta rischiosa. Consenti noto Il bene è sempre meglio quando è un'opzione. Pertanto, la conversione in un tipo intero fornirà sempre più sicurezza rispetto al tentativo di impedire stringhe specifiche. Le dichiarazioni preparate forniscono un eccellente livello di protezione.
Guarda l'articolo di Wikipedia sulla Mitigazione dell'iniezione SQL .
Supponendo che il parametro GET 'id' in cifre solo, la cosa migliore da fare è controllare se ID veramente contiene solo cifre, ad esempio convertendolo in INT (e prendere l'eccezione se ce ne sono), e non alcune cose brutte come virgolette / slash / caratteri codificati / ecc.
In generale, preferisco avere una variabile intera reale poiché so perfettamente che contiene solo cifre, piuttosto che una stringa di escape che potrebbe contenere alcuni caratteri strani ..
Leggi altre domande sui tag sql-injection