La sicurezza delle applicazioni è un argomento di primo piano, sia per le aziende che producono il software, sia per le aziende tradizionali che si trovano sempre più digitalizzate e interconnesse, in cui la maggior parte dei processi aziendali sono ormai gestiti attraverso software e applicazioni in Cloud.
La sicurezza delle applicazioni può arrivare a coinvolgere l’intero ecosistema aziendale: dalla protezione dei dati sensibili degli utenti, all’operatività quotidiana e quindi la produttività, fino alla salvaguardia dell’immagine dell’azienda stessa. Tutte queste variabili hanno effetti diretti sul profitto dell’azienda.
Nel corso degli anni, stiamo infatti assistendo a casi sempre più frequenti di attacchi informatici originati proprio dall’accesso attraverso vulnerabilità delle applicazioni, con ingenti conseguenze sulle aziende vittima.
Secondo il Verizon Data Breach Investigation Report 2022, uno dei report di riferimento a livello mondiale per le statistiche relative alle violazioni di dati, nell’ultimo anno circa il 70% di tutte le violazioni di dati analizzate sono state realizzate sfruttando debolezze di sicurezza delle applicazioni web.
Nel corso della nostra attività quotidiana di sicurezza intrusiva e di consulenza per la sicurezza informatica in aziende di svariate dimensioni e caratteristiche, sono frequenti i casi in cui rileviamo errori o distrazioni apparentemente ininfluenti, ma che se sfruttate da un utente malintenzionato possono provocare conseguenze ad alta criticità.
A questo proposito, abbiamo trovato molto interessante un approfondimento di Nick Merrit, Vice Presidente di Halo Security, pubblicato su DarkReading , che si è dichiarato poco stupito dal dato emerso dal Verizon VDBI, in quanto in diversi anni di esperienza di penetration test ha spesso rilevato gli stessi errori che si ripetono.
Cos’è un penetration test?
Il penetration test è una simulazione di attacco informatico, realizzata in ambiente “protetto”, che viene utilizzata per mettere alla luce le vulnerabilità del software che possono consentire ad un attaccante di assumerne il controllo o introdursi nel codice per eseguire codice malevolo. Scopri i dettagli del penetration test.
Merrit ha quindi fornito il suo contributo alla consapevolezza degli sviluppatori elencando i 5 errori di sicurezza che più spesso ha rilevato nel codice delle applicazioni che ha sottoposto a test di sicurezza, che riteniamo utile proporre qui di seguito.
Sottovalutare i rischi del cross-site scripting (XSS)
Il cross-site scripting è da lungo tempo una delle vulnerabilità più utilizzate per gli attacchi informatici ed è classificato da OWASP (Open Web Application Security Project) tra le 10 minacce più critiche per la sicurezza del software, anche se dal 2021 è stato ricompreso all’interno del gruppo di vulnerabilità di tipo “injection”.
Anche se meno diffusa rispetto al passato, rimane una tecnica molto critica e viene ancora rilevato di frequente durante i penetration test.
Spesso si considera l’XSS una minaccia a basso rischio, quando invece può comportare violazioni di sicurezza con impatti anche gravi.
Alcuni esempi di attacchi realizzabili attraverso XSS sono infatti: l’ottenimento del controllo di un account, il furto di dati e la compromissione dell’infrastruttura di un’applicazione.
In un sito WordPress, un attacco XSS ad un amministratore consente all’attaccante di caricare plug-in e di eseguire payload dannosi sul server. Solitamente, gli attaccanti utilizzano tecniche di ingegneria sociale per indurre l’amministratore a cliccare un link dannoso e dare avvio all’attacco vero e proprio.
Inoltre, l’uso di codice custom offre sempre una possibile via d’accesso alle intrusioni e andrebbe sempre sottoposto a code review in fase di rilascio.
Monitorare le applicazioni soltanto con scanner automatici
Gli scanner automatici solitamente utilizzano tecniche di fuzzing, ma possono generare falsi positivi.
Inoltre, gli scanner non sono quasi mai idonei ad analizzare le applicazioni web moderne e non garantiscono risultati eccellenti per la verifica di applicazioni JavaScript single page, WebAssembly e Graph.
Possono pertanto essere un ottimo strumento di supporto per individuare le vulnerabilità di livello macro, ma per l’analisi approfondita delle vulnerabilità di un’applicazione web non si può prescindere dalla componente umana e dal caricamento di payload manuali.
Utilizzare sistemi di autenticazione fai da te o implementati male
Il sistema di autenticazione costituisce gran parte della protezione di un’applicazione web, e se non viene compilato e implementato correttamente può trasformarsi in un serio rischio.
Ad esempio, conferma Merrit che spesso con i penetration test si trovano falle di sicurezza nel processo di recupero password se il codice del workflow è stato scritto da zero. Gli errori di frequente consentono di ottenere dati di altre utenze o privilegi più elevati rispetto al ruolo utilizzato.
Questi sono tipici esempi di vulnerabilità che possono garantire agli attaccanti la possibilità di gestire, bloccare o eliminare utenti per prendere il controllo dell’applicazione.
Certamente la sicurezza non dipende solamente dal protocollo di autenticazione utilizzato, molto dipende anche da come viene implementato. Anche un protocollo di autenticazione standard con codice verificato e sicuro, se integrato in modo errato può “aprire più porte di quante ne abbia chiuse”.
Non considerare il lato vulnerabile delle logiche aziendali
Gli sviluppatori realizzano le funzionalità delle applicazioni per soddisfare l’esigenza di business del cliente e guardano il codice dal punto di vista di quella specifica esigenza.
Gli attaccanti informatici, invece, guardano il codice per trovare possibili vie d’accesso per compromettere quelle funzionalità a proprio vantaggio.
Sono due punti di vista completamente diversi, che consentono che si crei una zona d’ombra che i primi non vedono e i secondi possono sfruttare liberamente, il nostro ruolo di penetration tester consiste nel vedere quella zona prima degli attaccanti.
Un esempio di funzionalità strategica che può essere manomessa è il carrello degli e-commerce: nonostante la sua importanza, molto spesso non è sicuro ed è esposto a molteplici possibilità di manomissione, come la sostituzione di codici prodotto nel carrello, l’aggiunta di prodotti dopo il checkout e addirittura l’azzeramento del totale durante il pagamento.
Non sarebbe tuttavia corretto addossare agli sviluppatori la responsabilità delle vulnerabilità di sicurezza, in quanto il loro compito è soddisfare attraverso il codice le esigenze funzionali dell’azienda committente e molto spesso con tempistiche di consegna molto ristrette.
Limitare l’ambito d’azione del penetration test
Riprendiamo la differenza dei punti di vista dello sviluppatore e dell’attaccante, per valutare l’ambito di estensione di un’applicazione e di conseguenza l’ampiezza del penetration test che ne verifica la sicurezza.
Per lo sviluppatore, l’applicazione termina dove termina il suo codice e “si collega” ad altre risorse “esterne”, di cui non è responsabile. Ma quello è un confine invisibile agli occhi di un attaccante, che prende di mira un’applicazione anche e soprattutto nei lati che espone alle risorse che utilizza. E questo sarà l’ambito che dovrà analizzare il penetration tester.
Le applicazioni web possono dunque diventare molto complesse in base alla quantità di risorse che contengono e con cui si connettono. È importante informare i penetration tester e in generale gli auditor di sicurezza, di tutte le risorse esterne a cui si collega l’applicazione e le modalità in cui avviene la connessione.
Devono quindi, ad esempio, essere verificati anche i server API di back-end che abilitano la funzionalità dell’applicazione principale.
Dal punto di vista dello sviluppo di software e applicazioni, le società di sviluppo che comprendono in anticipo alcuni di questi rischi, molto comuni agli occhi degli addetti ai lavori in ambito cybersecurity, e mettono in atto procedure idonee ad evitarli, ottengono software più sicuri e punteggi più rosei nei penetration test di verifica.
Si tratta di rendere gli sviluppatori consapevoli dei framework e delle best practice di sicurezza, in modo che possano coniugare la libertà di coding con le esigenze di protezione del software. Attivare dei percorsi di training on the job orientati alla scrittura di software sicuro può essere sicuramente un asset utile sia per le aziende del settore che per developer indipendenti.
Inoltre, è sempre più frequente che le tempistiche di sviluppo e rilascio del software siano dettate da tempi di mercato sempre più stringenti, portando inevitabilmente a trascurare le verifiche di sicurezza e le attività di code review prima del rilascio. Al contrario, la sicurezza delle applicazioni e la convalida del codice sicuro sono attività sempre più strategiche, che dovrebbero essere previste e pianificate prima a monte e poi in parallelo alle fasi di sviluppo delle funzionalità software.
A completamento del ciclo di sviluppo dovrebbero essere previste opportune attività di testing prima e dopo la pubblicazione dell’applicazione.