Livello di astrazione SQL: un meccanismo preventivo per SQLi?

4

Durante l'esecuzione di un pentest per un'applicazione basata su Java mi sono imbattuto in un errore SQL (in realtà HQL) semplicemente inserendo una virgoletta singola in uno dei parametri della richiesta e interrompendo la sintassi della query. Ma poiché l'applicazione utilizzava Hibernate Query Language come strato intermedio tra l'applicazione e il database, non ero in grado di accedere direttamente al database.

HQL non supporta i controlli basati su Union o time delay che generalmente sfruttiamo come pentesters. Sono stato in grado di estrarre tutte le voci dalla tabella in questione. Si noti che quando l'iniezione è stata trovata in una semplice funzionalità di ricerca non c'erano dati riservati nella tabella. Non ero in grado di estrarre alcun database o informazioni relative al sistema.

Ho già esaminato questa domanda . La mia domanda qui è, può usare un livello di astrazione come questo essere suggerito come misura preventiva durante la fase di sviluppo di un'applicazione? Perché secondo me può davvero minimizzare il potenziale di danno di una vulnerabilità SQLi (Almeno nel mio caso specifico in cui non ci sono dati reali importanti nel database)

Mi sto perdendo qualcosa di importante qui?

    
posta Shurmajee 26.05.2014 - 22:10
fonte

2 risposte

2

L'uso di un livello di astrazione non è una prevenzione significativa; le applicazioni che utilizzano tali livelli sono ancora spesso vulnerabili all'iniezione SQL.

Seguendo il tuo esempio di Hibernate, alcuni modi per interrogare sono sicuri; alcuni modi non sono sicuri. In realtà non ho mai trovato un esempio come quello che descrivi che è parzialmente sicuro, ma ha senso. Mi sono imbattuto in diversi che sono efficacemente l'iniezione SQL diretta.

Quindi, con un livello di astrazione in atto, si sta ancora facendo affidamento sugli sviluppatori per utilizzare l'API di query sicura. Questo non è molto diverso dalle interfacce SQL standard (come JDBC) dove esiste un'API sicura (query parametrizzate) e un'API non sicura (che crea dinamicamente SQL). In ogni caso, ti affidi agli sviluppatori per utilizzare quello giusto.

Potresti chiedertelo, qualcuno ha inventato una libreria di astrazione che ha solo un'API sicura? Se non ci sono API non sicure, non c'è nulla da abusare degli sviluppatori. Per quanto ne so, non esiste una libreria di questo tipo, e questo perché ci sono strane occasioni in cui è necessaria l'API non sicura. Ricorda che l'utilizzo dell'API non sicura non è necessariamente una vulnerabilità di sicurezza: il codice potrebbe utilizzare solo dati provenienti da fonti attendibili o potrebbe effettuare la sua sanificazione.

Quindi le difese sono:

  • Scegli una buona libreria, una con un'API sicura e facile da usare
  • Sviluppare standard di codifica che impongano l'API sicura e addestrare gli sviluppatori a utilizzare questo
  • Esegui peer review o analisi del codice statico per applicare l'uso dell'API sicura
  • Utilizzare test di penetrazione e WAF come ultimo livello di difesa
risposta data 26.05.2014 - 23:12
fonte
0

È fantastico che il livello di astrazione impedisca l'accesso diretto al database, ma non lo farei come unica protezione. Se hai un livello di astrazione sul posto perché l'applicazione si basa su di esso per l'uso, e aiuta a bloccare SQLi, quindi ottimo. Ma non implementerei uno strato di astrazione SOLO per motivi di sicurezza. Esistono molti altri modi documentati per sconfiggere SQLi che sono più facili da implementare. SQLi è tutto incentrato sull'input dell'utente e passarlo attraverso uno strato in più non sarà efficace quanto fermarlo prima che abbia la possibilità di avvicinarsi al database.

    
risposta data 26.05.2014 - 22:41
fonte

Leggi altre domande sui tag