L'uso di database non SQL elimina la necessità di proteggersi contro & # 8220; SQL injection & # 8221 ;?

Question

Questa può sembrare una domanda ovvia (o non così ovvia), ma lasciami spiegare. Sto codificando un sito di Google App Engine utilizzando la tecnologia di database di Google, BigTable. Tutti i programmatori di App Engine sapranno che Google ha un linguaggio di query limitato chiamato GQL. Di conseguenza, sono tentato di non effettuare alcun controllo per l'iniezione di SQL (o GQL) nella mia app poiché presumo che Google non stia utilizzando una query di stringa non elaborata sui suoi metodi di back-end per recuperare i dati.

Inoltre, le librerie per tecnologie DB come CouchDB, MongoDB e altri database di oggetti o documenti (aka NoSQL) sembrano ovviare alla necessità di verificare se un utente malintenzionato sta iniettando comandi di manipolazione del database. Spesso dispongono di librerie che mappano direttamente gli oggetti nel database in modo che si obiettino nella lingua prescelta. So che ci sono anche molte librerie SQL che lo fanno, ma suppongo che a un certo livello stiano combinando i parametri per eseguire una query su una stringa, e quindi devo ancora usare la protezione SQL Injection anche con quei framework.

Sono miope? O è solo una questione di tempo prima che il prossimo grande sistema DB prenda piede e poi vedrò l'iniezione in quei sistemi?

Answer 1

I buchi di “Iniezione” hanno a che fare con disallineamenti del contesto di testo. Ogni volta che inserisci una stringa di testo in un altro contesto di stringa, devi eseguire la codifica per adattarla al contesto modificato. Sembra seducentemente semplice mettere insieme le stringhe alla cieca, ma la difficoltà dell'elaborazione delle stringhe è ingannevole.

I database con un'interfaccia puramente basata su oggetti sono immuni alle vulnerabilità dell'iniezione, proprio come le query con parametri sono in SQL. Non c'è niente che un attaccante possa mettere nella sua stringa per uscire dal contesto letterale in cui lo hai inserito.

Ma GQL in particolare non è uno di questi. È un linguaggio di query di stringa e se si concatena materiale non attendibile non attendibile in una query come " WHERE title = '% s' " % title , sei vulnerabile quanto lo eri con SQL full-on. Forse le capacità limitate di GQL rendono più difficile lo sfruttamento che compromettere completamente l'applicazione, ma certamente non impossibile in generale, e nel migliore dei casi l'applicazione è ancora sbagliata e cadrà quando le persone tentano di usare legittimamente gli apostrofi.

GQL ha un'interfaccia di associazione dei parametri. Usalo Resisti al fascino dell'hacking delle stringhe.

Answer 2

Sottoinsiemi SQL come GQL ovviamente si preoccupano ancora di esso - ma i database puri non SQL come CouchDB, Voldemort, ecc. dovrebbero mettere & amp; ottenere dati senza preoccupazioni per attacchi in stile SQL injection.

Ciò, tuttavia, non ti scusa dal fare la convalida del contenuto, perché mentre potrebbe non rompere il database, potrebbe rompere l'applicazione e consentire cose come XSS (se si tratta di un'app Web).

Answer 3

Ogni volta che i dati provenienti o manipolati dall'input dell'utente vengono utilizzati per controllare l'esecuzione del codice, è necessario eseguire la sanificazione. Ho visto casi in cui il codice utilizzava l'input dell'utente per eseguire un comando senza disinfettare l'input. Non era stato sfruttato, ma se fosse stato sarebbe stato un orribile vettore di attacco.

Answer 4

SQl Injection è solo un sottoinsieme di un tipo di difetto di sicurezza in cui viene valutato qualsiasi input non controllato.

tecnicamente, puoi " iniettare " javascript, tra gli altri.