SQL Injection tramite Unicode

Naviga le tue risposte
4

Il mio team utilizza attualmente ASP.NET con MS SQL Server per il nostro software. La sicurezza è diventata importante da quando ho iniziato, in cui ci sono vulnerabilità di iniezione ovunque.

Data l'attuale integrazione con Oracle e MS SQL, la decisione aziendale non è mai stata di utilizzare query parametrizzate. Questo naturalmente è stato un problema.

L'implementazione di Trova e sostituisci e la whitelist dei parametri ha ridotto notevolmente il problema.

Il mio unico problema è che ho letto molto su Unicode e altre codifiche che sono la causa di SQL injection. Non lo capisco abbastanza. Attualmente disinfettiamo tutto in questo modo: 

        Const pattern As String = "^[a-zA-Z0-9.=,:\s\\/\']*$"
        term = term.Replace("'", "''")

        If Not Tools.ValidString(term, pattern) Then
            term = String.Empty
        End If 

    Public Shared Function ValidString(ByVal source As String, ByVal pattern As String) As Boolean
        If source = String.Empty Then Return True

        Dim params As Text.RegularExpressions.RegexOptions = Text.RegularExpressions.RegexOptions.None
        Dim regex As New Text.RegularExpressions.Regex(pattern, params)
        Dim match As Text.RegularExpressions.Match = regex.Match(source, pattern, params)
        Return match.Success
    End Function

Qualcuno ha un esempio in cui è possibile utilizzare l'iniezione unicode / codificata o solo un semplice esempio in cui questa espressione regolare non riuscirebbe a impedire l'iniezione di SQL.

Grazie

Aggiorna

Per favore non ho risposte relative allo standard SQL Injection. Conosco già molto questo. INOLTRE, per favore, smetti di postare dicendo di non usare la sanificazione delle corde. Nell'azienda non vi sono risorse a zero per spostare tutte le query in query parametrizzate con ADO.NET, ma anche in logica per utilizzare ODP.NET se il client utilizza oracle. OWASP menziona l'uso di whitelisting di caratteri se la parametrizzazione è fuori questione, quindi, come nell'espressione regolare, sono ammessi solo pochi caratteri. Non sto inserendo i caratteri nella lista nera, perché questo è stupido.

Non è richiesta alcuna conformità per i dati in nostro possesso. La sicurezza è per l'integrità del database, in quanto sarebbe un incubo se il contenuto fosse cambiato.

Il nostro software è un'applicazione cloud CMS e DMS di grandi dimensioni in uno, in cui il 99% del software è utilizzato internamente e solo una minoranza è esterna e viene utilizzata solo per la revisione pubblica e per commentare i documenti.

Dalla mia nuova comprensione dell'iniezione Unicode. Può verificarsi solo se i dati vengono codificati prima di essere inseriti nella query e pertanto l'iniezione Unicode si verifica solo nelle applicazioni con globalizzazione dei dati. Sto passando i campi di stringa grezzi direttamente nella query di stringa dopo la sanificazione di cui sopra.

Posso avere solo una risposta da un esperto in iniezione, chi può eseguire il backup del mio reclamo in base al quale Unicode non si applica alle mie circostanze?

    
posta Cyassin 03.04.2014 - 00:38
fonte

4 risposte

5

Esistono casi di Injection SQL che sfruttano la conversione implicita di Unicode omogeneo dai tipi di stringhe di caratteri Unicode (NCHAR, NVARCHAR) ai tipi di stringa di caratteri (CHAR, VARCHAR). Un personaggio come ʼ (U + 02BC) in NVARCHAR potrebbe scivolare attraverso la routine di escape e viene tradotto in ' (U + 0027) in VARCHAR , che può risultare in un'iniezione SQL quando tale stringa viene utilizzata per creare dinamicamente un'istruzione SQL.

Tuttavia, la tua convalida è abbastanza severa (solo i caratteri del blocco Basic Unicode latino e Caratteri di spazi bianchi Unicode ) e non riesco a pensare a casi in cui ciò non riuscirebbe.

    
risposta data 06.04.2014 - 14:06
fonte
2

L'unica cosa di cui hai più bisogno per interrompere l'SQL injection è un punto e virgola (;). Tuttavia, non è sempre semplice eliminarli. Ci sono situazioni in cui un punto e virgola viene utilizzato in un campo di testo come un carattere, non come un terminatore di comando SQL.

Ci sono molti articoli che descrivono in dettaglio come sia iniettare sia prevenire SQL nelle tue query.

If you write text output to a Web page, encode it using HttpUtility.HtmlEncode. Do this if the text came from user input, a database, or a local file.

Questo richiama alla mente uno dei metodi usati per proteggere dall'iniezione SQL: codifica i caratteri che causeranno problemi con quelli che non possono.

Specificamente per Unicode rispetto a qualsiasi altra codifica, dovrai comunque utilizzare le stesse tecniche per trovare e rimuovere o sostituire i caratteri offensivi nelle tue stringhe.

Aggiorna

Se codifichi le stringhe Unicode in qualcosa come / u0000, puoi lasciare la stringa codificata e metterla in sicurezza nel tuo database senza preoccuparti dell'iniezione SQL. Dovrai scrivere la routine che esegue la disinfezione, poiché non è integrata in SQL Server.

    
risposta data 03.04.2014 - 01:22
fonte
2

Se stai guardando come unicode può essere sfruttato, vedi questa domanda , se stai cercando una soluzione, ce ne sono davvero solo due che possono essere considerate davvero sicure: query parametrizzate e codifica di tutto il tuo input in hex o base64 o qualche altra codifica che non lascia aperta la possibilità di cambiare il contesto del valore.

Vorrei seriamente riconsiderare l'uso di query parametrizzate - che sono infatti notevolmente facili da usare, mentre io non conosco il tuo codice base, è generalmente abbastanza facile da cambiare. Particolarmente dopo l'introduzione dei metodi di estensione.

    
risposta data 03.04.2014 - 07:16
fonte
2

Per favore, per favore, per favore, non usare una regex fatta a mano per prevenire l'iniezione SQL. Non si dovrebbero mai scrivere le proprie funzioni di escape, filtraggio o disinfezione per impedire l'iniezione SQL, l'XSS, l'iniezione della shell o simili. Queste sono cose su cui ti basi su librerie incorporate e controllate per.

Dove puoi evitarlo, non utilizzare nemmeno una funzione di escape della libreria standard. Utilizza query con parametri.

Per prima cosa, questa escaping non sarà di aiuto se stai usando un valore intero non quotato alla fine di una query. In pseudocode: 

check ValidString(input)
query("SELECT * FROM table WHERE id=" + input)

L'utente può facilmente inserire 1 OR 1=1 per vedere tutte le righe in table .

... Oppure possono inserire 1 UNION ALL SELECT password,1,1 FROM password_table o simili. E ora l'output contiene tutte le password utente.

Stai dicendo che è impossibile tornare indietro e convertire tutto il codice SQL per utilizzare le query parametrizzate? Se è così, suppongo che sia meglio essere sicuro al 100% di citare sempre i valori SQL e non fare mai confronti o inserzioni di interi ...

Se fossi in te, convincerei la tua direzione e / o il tuo team che se la sicurezza è desiderata anche in minima parte, allora è necessario prendere tempo per riscrivere il codice in modo sicuro.

    
risposta data 03.04.2014 - 11:58
fonte

Leggi altre domande sui tag

Per chi ha una chiave e un testo cifrato, è possibile scoprire quale algoritmo di crittografia è stato utilizzato? Quante informazioni sulla sicurezza pubblicizzare?