Quali personaggi pericolosi devono essere filtrati dall'input dell'utente prima di essere utilizzati in una query DB2 SQL?

Question

Quali personaggi pericolosi devono essere filtrati dall'input dell'utente prima di essere utilizzati in una query DB2 SQL?

#1 da (8 voti)
#2 da (3 voti)
#3 da (0 voti)

6

Sto cercando di comprendere appieno come filtrare / sfuggire correttamente i caratteri pericolosi dall'input dell'utente che verranno interpolati in una query DB2 SQL.

Il routing di disinfezione che sto analizzando funziona in questo modo:

Rimuovi tutti i backslash (s / \\ //)
Sostituisci tutte le virgolette singole con virgolette singole doppie (s / '/' '/)

Il mio primo istinto è stato quello di esaminare una funzione di sanitizzazione db2 esistente, per verificare eventuali differenze. Così ho dato un'occhiata a db2_real_escape_string che, a quanto pare, è molto diversa: anteporre i backslash a caratteri speciali nell'argomento stringa. I caratteri preceduti da una barra rovesciata sono \ x00, \ n, \ r, \, ', "e \ x1a.

Alcune domande specifiche che ho sono:

Perché db2_real_escape_string () backslash-escape cita invece di raddoppiarli? Questo sembra scorretto.
La funzione di sanitizzazione che sto analizzando non riesce a uscire o filtrare \ x00, \ n, \ r, \ x1a, ". Come potrebbero questi personaggi essere maltrattati da un utente malintenzionato? Questa è la mia domanda principale.
Un'altra deficienza della mia funzione di sanitizzazione è che non è sensibile al charset, ma suppongo che questo non sia un problema perché db2, in questo caso, è configurato per l'uso con il set di caratteri predefinito (che sono la supposizione non è multi-byte). Quindi AFAIK, a meno che non sia stato configurato un set di caratteri multi-byte come GBK, gli attacchi di iniezione sql multi-byte come questa vulnerabilità nota in MySQL GBK non dovrebbe essere un problema.
Ci sono altre considerazioni / passaggi che mancano nella funzione di sanitizzazione che sto analizzando?

Capisco che l'utilizzo di query parametrizzate sia la soluzione più ovvia. Tuttavia, in questo caso, sono responsabile di A) determinare se il progetto corrente è sfruttabile e B) fornire una patch per la funzione di sanitizzazione (se necessaria).

modifica Sto fondamentalmente cercando di costruire un carico utile per l'injection di sql a prova di concetto, data la funzione di disinfezione di cui sopra e il seguente utilizzo: execute( " SELECT foo FROM bar WHERE col='" + my_sanitize($_GET['input']) + "'" )

Data la progettazione della funzione di sanitizzazione corrente (rimuovere le barre rovesciate e le virgolette singole doppie), esiste un modo per rompere le virgolette singole come nell'esempio di utilizzo precedente?

Grazie per l'assistenza!

sql-injection web-application appsec penetration-test

posta octagonC 10.03.2013 - 00:03

fonte

3 risposte

8

"Sanitizzazione" è fragile. Devi pensare a ogni singolo dettaglio di come il database interpreta "caratteri speciali", e devi tenerne traccia da vicino, nel caso in cui una nuova sotto-versione del database introduca caratteri speciali extra. Questo è un lavoro estenuante e spesso fallisce.

Il modo (molto) preferito di inserire i dati utente nelle query SQL è utilizzare la istruzione preparata . Questo sarà più facile per te (il programmatore), più robusto, più sicuro e abbastanza probabilmente più veloce.

risposta data 10.03.2013 - 01:50

fonte

0

Per la convalida dell'input dell'utente critico, che può infrangere le stringhe SQL, farei una "stringa / stringa di caratteri valida" e quindi verificare che ogni carattere nell'input dell'utente sia all'interno della stringa consentita.

Come se si consentissero solo numeri, la stringa potrebbe essere fatta come:

function ParseIntoValid(userinput)
{
    string validOutput = "";
    Array allowedChars = new Array("0123456789");

    foreach (char c in userinput[])
    {

        if (c.instr(allowedChars))
        {

            // if this is a parser, then add valid chars to new output
            validOutput += c;
         }
         else
         { 
            // exit loop and return false/error if you just need a check or just ignore the illigal chars
         }
    }
}

puoi facilmente integrare questo controllo in un semplice "CheckIfValid (input)" o "ParseIntoValid (input)" a seconda del tuo obiettivo.

Analizzando e non solo controllando, ottieni un output valido, forse ha meno caratteri, ma se l'utente inserisce un singolo carattere illigal per errore, questa funzione aiuterà il "buon utente" e il "cattivo utente" ancora non ottenere accesso usando loro.

risposta data 11.03.2013 - 12:30

fonte

Leggi altre domande sui tag sql-injection web-application appsec penetration-test

Dove viene memorizzata la mia password su Windows 7? Quanto guadagna una richiesta GET su HTTPS a un intercettatore

score 3 · Accepted Answer

"La funzione di sanitizzazione che sto analizzando non riesce a uscire o filtrare \ x00, \ n, \ r, \ x1a,". Come potrebbero questi personaggi essere maltrattati da un aggressore? Questa è la mia domanda principale.

Le rappresentazioni esadecimali \ x00 e \ x1a per uno spazio vuoto e un carattere sostitutivo. \ n e \ r sono ritorni a capo e ritorni a capo.

Nella maggior parte dei casi non penso che questi sarebbero personaggi terribilmente esplosivi. Pensando mentre scrivo qui, potresti essere in grado di usare \ x00 (vuoto) per inondare un buffer statico. Un personaggio \ x1a (sub) potrebbe avere un potenziale se il sistema è in modalità binaria, o se stai eseguendo lo streaming binario, per indurre il sistema a pensare che hai raggiunto la fine di un file prematuramente.

Come per \ n & \ r ... Non riesco a pensare a molto.

A seconda della quantità di informazioni che hai / può avere sul sistema, potresti voler indagare sulle diverse codifiche dei caratteri possibili. A volte puoi fare cose come passare un UTF-8 in un processo impostato su UTF-7 (un esempio casuale, non qualsiasi applicazione pratica a cui sto pensando) e ottenere risultati entusiasmanti dalla magia degli errori di conversione.

Buona fortuna con il tuo pen-test.