Impatto dell'SQL Injection
L'iniezione SQL (SQLi) consente a un utente malintenzionato di interferire con le query effettuate da un'applicazione sul proprio database [S1]. L'impatto principale include l'accesso non autorizzato a dati sensibili come password utente, dettagli della carta di credito e informazioni personali [S1].
Oltre al furto di dati, gli aggressori possono spesso modificare o eliminare i record del database, portando a cambiamenti persistenti nel comportamento delle applicazioni o alla perdita di dati [S1]. Nei casi di gravità elevata, SQLi può essere intensificato per compromettere l'infrastruttura back-end, consentire attacchi di tipo Denial of Service o fornire una backdoor persistente nei sistemi dell'organizzazione [S1][S2].
Causa principale: gestione degli input non sicura
La causa principale dell'SQL injection è la neutralizzazione impropria di elementi speciali utilizzati in un comando SQL [S2]. Ciò si verifica quando un'applicazione costruisce query SQL concatenando l'input influenzato dall'esterno direttamente nella stringa di query [S1][S2].
Poiché l'input non è adeguatamente isolato dalla struttura della query, l'interprete del database potrebbe eseguire parti dell'input dell'utente come codice SQL anziché trattarlo come dati letterali [S2]. Questa vulnerabilità può manifestarsi in varie parti di una query, incluse le istruzioni SELECT, i valori INSERT o le istruzioni UPDATE [S1].
Correzioni e mitigazioni concrete
Utilizza query con parametri
Il modo più efficace per prevenire l'SQL injection è l'uso di query con parametri, note anche come istruzioni preparate [S1]. Invece di concatenare stringhe, gli sviluppatori dovrebbero utilizzare meccanismi strutturati che impongono la separazione dei dati e del codice [S2].
Principio del privilegio minimo
Le applicazioni devono connettersi al database utilizzando i privilegi più bassi richiesti per le loro attività [S2]. Un account di un'applicazione Web non deve avere privilegi amministrativi e deve essere limitato alle tabelle o alle operazioni specifiche necessarie per la sua funzione [S2].
Convalida e codifica dell'input
Sebbene non sostituisca la parametrizzazione, la convalida dell'input fornisce [S2] di difesa approfondita. Le applicazioni devono utilizzare una strategia di accettazione nota-buona, convalidando che l'input corrisponda ai tipi, alle lunghezze e ai formati previsti [S2].
Come lo esegue il test FixVibe
FixVibe copre già l'iniezione SQL tramite il modulo scanner active.sqli con gate. Le scansioni attive vengono eseguite solo dopo la verifica e l'attestazione della proprietà del dominio. Il controllo esegue la scansione degli endpoint GET della stessa origine con parametri di query, stabilisce una risposta di base, cerca anomalie booleane specifiche di SQL e segnala un risultato solo dopo la conferma temporale su più lunghezze di ritardo. Le scansioni del repository aiutano anche a individuare la causa principale in anticipo tramite code.web-app-risk-checklist-backfill, che contrassegna le chiamate SQL non elaborate create con l'interpolazione del modello.