Mettere in sicurezza gli applicativi: i rischi della vulnerabilità informatica

Vulnerabilità sicurezza informatica: parliamo di application security

Ci sembra ridondante sottolineare quanto il tema della vulnerabilità informatica sia attuale e concreta, a causa dei tentativi di segmentazione degli applicativi software da parte dei cyber-attacchi. Il rischio di esporre informazioni aziendali confidenziali o dati personali sensibili degli utenti ha spinto molte aziende a investire nella sicurezza dei propri applicativi web.

Gli utenti danno ormai per scontata la possibilità di poter compiere sul web operazioni di acquisto ed inserimento di informazioni personali nella serenità di essere protetti da furti di identità, estrazione di password, tentativi di phishing o invio di materiale non desiderato. Per questo motivo, proteggere i dati degli utenti non è più una questione di sola sicurezza, ma anche di competitività. Un’azienda che a seguito di un attacco, espone a rischi i dati dei propri consumatori, subisce tra le altre conseguenze anche un danno d’immagine che danneggia profondamente il rapporto di fiducia con gli utenti.

La sicurezza degli applicativi web diventa quindi un prerequisito fondamentale per la fidelizzazione dei consumatori, e si traduce in un importante volano di crescita per le aziende che offrono servizi e prodotti attraverso canali web.

Per questo motivo abbiamo deciso pubblicare un articolo che avesse come target di riferimento proprio la sicurezza degli applicativi e le tecnologie attualmente disponibili per la valutazione della vulnerabilità informatica.

Scarica il White Paper sull’Application Security Testing

Argomento di questo contenuto è quindi l’application security che ha come obiettivo la sicurezza del codice sorgente di un applicativo e la protezione del software da minacce informatiche. In particolar modo le applicazioni web non aggiornate o scritte senza una particolare attenzione alla qualità del codice rappresentano un rischio evidente per attacchi esterni e manipolazioni.

Analisi vulnerabilità informatica: quali sono i pericoli

Le iniezioni di codice SQL, meglio note come SQL-injections, sono un tipico esempio di come sia possibile sfruttare la vulnerabilità informatica di un’applicazione web per manipolare il database nel back-end, ed accedere a informazioni sensibili. Questa tecnica di hacking non richiede l’uso di strumenti particolari, e prende di mira qualsiasi architettura software utilizzata per realizzare siti web che interroghino un database relazionale (qualunque sia il linguaggio di programmazione web based, o il tipo di server DB).

Ad esempio, un utente che raggiunge l’indirizzo della pagina di login su un server (sito web), visualizza sul proprio client una pagina HTML elaborata in locale dal server web ed inviata al browser (si immagini, sempre per esempio, un applicativo scritto in PHP con un database MySQL). Quando l’utente inserisce i propri dati sul form di login, quest’ultimo li invierà al server web affinché possa interrogare il proprio database, e predisporre le informazioni richieste dopo aver verificato le credenziali inserite con quelle archiviate. Un esperto di sintassi SQL potrebbe sfruttare le pagine del sito web che prevedano un dialogo con il database (come il form di login), per inviare particolari istruzioni inconsuete con l’obiettivo di ottenere un accesso non autorizzato all’applicazione stessa per ottenere dati sensibili, modificarli o cancellarli.

Scarica il White Paper sull’Application Security Testing

È quindi fondamentale che vengano adottate in fase di sviluppo dell’applicazione web, delle misure di protezione che minimizzino il rischio di vulnerabilità informatica, come la messa in sicurezza del codice deputato alla gestione dei moduli di autenticazione e delle pagine di ricerca.

Valutazione di vulnerabilità informatica: lo standard OWASP

Nel 2001 fu avviato da Mark Curphey, Dennis Groves, e Jeremiah Grossman un progetto open-source chiamato Open Web Application Project (meglio noto come OWASP), con l’obiettivo di fornire linee guida, strumenti e metodologie per migliorare la sicurezza delle applicazioni. Divenuto ormai uno standard e punto di riferimento mondiale per tutta la comunità di sviluppatori, si occupa (anche) di pubblicare la OWASP Top 10, ovvero la classifica aggiornata dei rischi più critici per le organizzazioni, tra cui figurano (nel 2021):

1. Broken Access Control (Controllo di accesso interrotto): Il controllo dell’accesso applica criteri che limitano gli utenti affinché non possano agire al di fuori delle autorizzazioni previste. Errori o malfunzionamenti portano ad un’assegnazione non corretta delle restrizioni, che permette ad utenti semplici di utilizzare funzioni riservate a privilegi superiori.
2. Cryptographic Failures (Errori crittografici): ovvero errori nella cifratura e protezione dei dati (cifratura at rest ed in transit, autenticazione, autorizzazione, ecc…) che comportano l’esposizione di dati personali e privati.
3. Injection (Iniezione): come precedentemente illustrato si parla di injection quando è possibile nascondere e trasmettere istruzioni attraverso un’applicazione ad altri sistemi con lo scopo di accedere a informazioni riservate o eseguire comandi.
4. Insecure Design (Design Insicuro) questa categoria molto ampia rappresenta diversi punti deboli, che comprendono progettazione non sicura e implementazione non sicura. Uno dei fattori che contribuiscono a una progettazione non sicura è la mancanza di profilazione del rischio aziendale inerente al software o al sistema in fase di sviluppo, e quindi l’impossibilità di determinare quale livello di progettazione di sicurezza è richiesto.
5. Security Misconfiguration  (Errore configurazione di sicurezza): questo tipo di vulnerabilità informatica si verifica quando un componente dell’applicazione è esposto agli attacchi a causa di un’opzione di configurazione non sicura o di una configurazione errata.
6. Vulnerable and Outdated Components (Componenti vulnerabili e obsoleti): questo tipo di vulnerabilità includono componenti utilizzati direttamente ma anche dipendenze nidificate. In particolare, il software diventa vulnerabile se all’interno dell’applicativo vengono eseguiti con privilegi completi librerie e framework non aggiornati o non supportati. Questo include anche il sistema operativo, il server Web/applicativo, il sistema di gestione dei database (DBMS), le applicazioni, le API e tutti i componenti, gli ambienti di runtime e le librerie.
7. Identification and Authentication Failures (Errori di identificazione e autenticazione): Questi tipo di vulnerabilità può verificarsi quando un’applicazione, ad esempio, non impedisce attacchi automatici come credential stuffing o attacchi di forza bruta per decifrare le password. Anche difetti nella reimpostazione della password o nei flussi di ripristino possono esporre l’applicativo a questi rischi.
8. Software and Data Integrity Failures (Errori di integrità dei dati e del software): rientrano in questa categoria le modifiche involontarie ai dati come risultato di un’operazione di archiviazione, di recupero o di elaborazione (sono compresi in questo caso anche gli errori umani ed i guasti hardware imprevisti).
9. Security Logging and Monitoring Failures (Errori di registrazione e monitoraggio della sicurezza): questo tipo di vulnerabilità si presenta quando un evento critico per la sicurezza non viene disconnesso correttamente ed il sistema non è monitorato.
10. Server-Side Request Forgery (La falsificazione della richiesta lato server): questo tipo di vulnerabilità si verificano ogni volta che un’applicazione web recupera una risorsa remota senza convalidare l’URL fornito dall’utente. In questo modo si dà la possibilità ad un utente malintenzionato di costringere l’applicazione a inviare una richiesta predisposta a una destinazione imprevista, anche se protetta da firewall, VPN o un altro tipo di elenco di controllo dell’accesso alla rete (ACL).

Proprio per fronteggiare la numerosità e la complessità crescente di questo tipo di attacchi sono stati sviluppati degli strumenti di analisi automatica della qualità del codice, e della conformità delle librerie e del codice di terze parti rispetto agli ultimi aggiornamenti disponibili.

Scarica il White Paper sull’Application Security Testing

Tali strumenti, che rientrano nell’ambito dell’application security testing (AST) vengono utilizzati sia iterativamente nei cicli di sviluppo che portano al rilascio di un nuovo applicativo o di una nuova release sia a posteriori per scansionare l’intero archivio di sorgenti che compone un applicativo già costituito.

Anche questo è un sintomo di una consapevolezza emergente che sta progressivamente guadagnando consensi presso la comunità degli sviluppatori. La sicurezza del codice è una responsabilità condivisa che deve coinvolgere tutto il team, creando procedure idonee e specifiche per ogni stadio del ciclo di vita del software (planning, analysis, design, development, testing, implementazione, e manutenzione). L’aver compreso che le questioni di sicurezza sono troppo vaste ed importanti per essere affrontate da un solo reparto (ad esempio quello di Quality Assurance), è stato fondamentale nel dare vita ad un nuovo paradigma, detto DevSecOps che sta gradualmente sostituendo quello di DevOps.

A fianco delle consapevolezze dalla comunità dev ed IT, sta maturando anche nelle divisioni di management e governance aziendale l’attenzione cosciente ai rischi ed alle opportunità correlate alla sicurezza degli applicativi. Un’azienda che investe nella manutenzione delle vulnerabilità informatica sta tutelando il proprio know how, i dati e le relazioni contrattualizzate e soprattutto la privacy dei propri utenti.