In questa seconda parte analizziamo gli interventi da attuare per la revisione del database in ottica di modernizzazione, dal punto di vista della sicurezza. I rischi legati ad una gestione scorretta del database devono essere rimossi dal software con un’attenzione particolare agli aspetti più pericolosi.
Vediamo quindi alcune delle regole principali da tenere sotto controllo.
Evitare la mancanza di controlli per la SQL Injection
La SQL Injection è una delle tecniche hacking utilizzate per l’inserimento e l’esecuzione di codice SQL non previsto all’interno di applicazioni web basate su database. Questo fenomeno avviene quando alcuni dati vengono inviati ad un iinterprete dei dati che non li gestisce correttamente permettendo all’hacker di accedere ad informazioni riservate o di eseguire comandi. Nell’ambito delle Common Weakness Enumerations (CWEs) si tratta della ben nota CWE-89: SQL Injection, inclusa nelle OWASP Top 10: CWE-89: Improper Neutralization of Special Elements used in an SQL Command
Un attacco di SQL Injection è estremamente utile all’hacker che lo implementa per riuscire ad ottenere l’accesso esteso al database (o back-end del software). Questo significa che il criminale informatico è fermamente interessato a reperire informazioni di carattere sensibile, come l’elenco degli utenti di un sito web, oppure i dati finanziari o societari. Nella peggiore delle ipotesi, un attacco informatico di iniezione SQL può portare alla modifica dei dati o alla loro eliminazione.
L’attacco si verifica quando non viene filtrato opportunamente l’input passato dall’utente, rendendo possibile per un aggressore l’alterazione della struttura originaria della query SQL attraverso l’utilizzo di caratteri speciali (ad esempio apici e virgolette) o mediante la concatenazione di costrutti multipli (ad esempio utilizzando la keyword SQL UNION).
La prevenzione di un attacco di SQL injection può essere fatta attraverso una corretta validazione dell’input (tipologia di dato, lunghezza massima, formato, contenuto), accettando solo una lista predefinita di caratteri permessi e identificando una denylist di caratteri potenzialmente pericolosi. Inoltre è consigliato l’uso di query parametrizzate e di stored procedure.
Evitare procedure con operazioni di Insert, Update, Delete, Create Table o Select senza la gestione dell’errore
Non gestire l’errore o non gestirlo correttamente durante qualsiasi tipo di operazione su un database, può portare alla corruzione dei dati e a comportamenti incontrollati dell’applicazione con ripercussioni sulla stabilità e sulla sicurezza.
In SQL Server e Sybase, ad esempio, la gestione dell’errore prevede l’utilizzo della variabile @@ERROR oppure del blocco TRY…CATCH. In Oracle PL/SQL nelle Functions e nelle Procedures la gestione dell’errore dopo una istruzione SQL prevede l’utilizzo dell’istruzione EXCEPTION WHEN.
La gestione dell’errore oltre ad essere presente, deve rispondere anche ad ulteriori regole che vediamo qui di seguito:
- Utilizzare sempre la clausola WHEN OTHERS nella gestione degli errori SQL
- Non usare mai WHEN OTHER THEN NULL nella gestione degli errori SQL
- Evitare “EMPTY CATCH blocks”
Non usare la clausola WHEN OTHER o omettere le istruzioni da eseguire in caso di errore, non consente di intercettare l’errore alle procedure chiamanti generando un comportamento imprevisto dell’applicazione e rendendo molto più oneroso il troubleshooting in caso di anomalie.
Inoltre, i messaggi di errore di default del database spesso includono informazioni interne, che possono aiutare gli aggressori a identificare una vulnerabilità o pianificare un attacco. È necessario quindi assicurarsi che tutto il codice procedurale utilizzi la gestione degli errori, per evitare che i messaggi di errore predefiniti raggiungano l'utente.
Evitare l’utilizzo di TRUNCATE TABLE
Sebbene l'istruzione TRUNCATE TABLE possa essere utile in alcune circostanze dal punto di vista delle prestazioni, è problematica perché l'eliminazione dei dati della tabella non viene registrata nei log delle transazioni e quindi tale operazione non è reversibile, al contrario dell’istruzione DELETE FROM. Per evitare l’uso accidentale di tale istruzione una tecnica potrebbe essere quella di creare una foreign key fittizia alla tabella in modo che l’operazione di TRUNCATE vada in errore.
Evitare l’utilizzo di oggetti temporanei (SQL-Server, Sybase T-SQL )
Triggers, Views, Functions e Procedures non dovrebbero usare Oggetti temporanei. Gli oggetti temporanei possono avere un impatto negativo sulle prestazioni e sulla scalabilità. Se il tempdb è pieno a causa di oggetti temporanei in eccesso, il server smetterà di funzionare. Ci sono alcuni casi in cui a causa di query complesse o che agiscono su una mole notevole di dati è utile utilizzare oggetti temporanei per splittare in più step l’estrazione dei dati. Pertanto, se non si può fare a meno di utilizzarli, bisogna sempre sapere quali sono gli oggetti temporanei utilizzati dalla propria applicazione e intraprendere le azioni appropriate per pulirli/rimuoverli se non sono necessari.
In ottica di modernizzazione e di revisione del Database, le aziende dovrebbero definire e applicare policy che richiedono il controllo del codice automatizzando il più possibile.
Coinvolgere i DBA e gli architetti dei dati e controllare periodicamente le istruzioni SQL può migliorare drasticamente la disponibilità e la recuperabilità del software e, molte volte, anche le prestazioni dello stesso.
L’utilizzo di CAST Imaging e le Management&Engineering Dashboard di CAST consente di realizzare l’analisi statica del codice e rilevare sistematicamente le violazioni di sicurezza delle componenti SQL e non solo. La piattaforma di CAST gestisce infatti numerose regole e metriche relative al codice SQL in diversi tipi di Database, anche no-SQL.
Per analizzare i database SQL (Microsoft, Oracle, Sybase, …) che fanno parte di un'applicazione, la piattaforma CAST richiede che i database vengano forniti per l'analisi in formato file "offline". Infatti, CAST non si connette al database durante l'analisi in quanto vengono analizzati i file "offline" con la struttura del database e il codice sql (View, Procedures, Functions, Triggers). Questo metodo non invasivo non ha impatto quindi sulle prestazioni dell’applicazione e consente di eseguire la consegna da parte di un DBA dedicato. I file "offline" possono essere generati dallo strumento CAST Database Extractor o forniti direttamente dall’owner dell’applicazione insieme al codice sorgente.
Dall’esito delle analisi effettuate tramite la Engineering Dashoards di CAST è possibile effettuare un’analisi dettagliata dei difetti critici tramite la navigazione in drill-down fino al codice sorgente.
Inoltre, è possibile implementare dei piani di rimedio ottimizzati in base all’impatto per la risoluzione delle problematiche presenti nel codice e che costituiscono un rischio per l’applicazione.
Comments: