Le applicazioni Web rappresentano, nell’odierna società, uno dei principali veicoli di comunicazione oltre che essere un canale privilegiato di azione nel cyberspace.
Purtroppo, però, quanto più raggiungono diffusione e popolarità, tanto più diventano un appetibile bersaglio per i criminali informatici, sia per azioni dimostrative, sia per ottenere un illecito guadagno economico, sia semplicemente per screditare la vittima da un punto di vista reputazionale.
Indice degli argomenti
Applicazioni Web: dove si nascondono i pericoli
L’organizzazione internazionale OWASP (Open Web Application Security Project), ha identificato “le big 10”, le dieci minacce più rilevanti per la sicurezza delle piattaforme Web, cui corrisponde un impatto sulla confidenzialità, integrità e disponibilità dei dati (personali e non), processati al loro interno.
Analizziamole nel dettaglio.
Code injection
La cosiddetta “code injection” consiste nell’ introdurre una stringa, suscettibile di essere eseguita, all’interno del sistema informatico, modificandone il flusso dell’esecuzione.
Un esempio molto diffuso è quello dell’SQL Injection, ma l’attacco ha caratteristiche analoghe anche su protocollo LDAP (Lightweight Directory Access Protocol), utilizzato da Active Directory per immagazzinare informazioni su oggetti e utenti del dominio aziendale.
Se infatti il linguaggio lato server che interroga la base dati non esegue i controlli opportuni sui valori dei campi richiesti, oppure non è parametrizzato[1], l’attaccante riesce ad interrompere con il carattere “;” la stringa in esecuzione e ad eseguire query sul database sottostante l’applicazione, fino ad ottenerne il pieno controllo.
L’impatto dell’occorrenza della minaccia può andare dalla semplice perdita di integrità del front end del sito (in ipotesi di defacement), alla ben più rilevante perdita di riservatezza e di disponibilità di dati (personali, sensibili e non), con conseguenze reputazionali ma anche economiche (pensiamo ai casi di risarcimento per danni o alle sanzioni amministrative dell’Autorità Garante).
È altresì da rilevare la possibilità di ricondurre sotto questa categoria di minaccia anche altri canali di attacco, i cosiddetti “command injection attacks”, di cui distinguiamo, per semplicità, 3 tipologie:
- iniezioni di comandi attraverso shell: accedere alla riga di comando di un server (in questo caso, la macchina che ospita il sito Web), è uno degli obiettivi archetipici di un hacker; qualora egli riuscisse, sfruttando una vulnerabilità applicativa, ad ottenere un canale di esecuzione da shell (pensiamo alle funzioni dei linguaggi lato server come sistem(), StartProcess(), java.lang.Runtime.exec() ecc.), l’impatto risultante potrebbe essere disastroso, sotto tutti i profili della sicurezza delle informazioni.
- incorporazione di contenuti HTML: come per la SQL-injection, qualora il codice dell’applicazione sia stato progettato senza la previsione dei controlli tesi alla neutralizzazione degli script o dei tag HTML, è relativamente semplice concatenare stringhe contenenti “porzioni di pagina” non desiderate, anche sovrapponibili (e resi trasparenti, quindi invisibili) al contenuto lecito ed in grado di attivare malware opportunamente predisposti, al clic del mouse sul nuovo componente ben dissimulato.
- iniezione di file: se l’applicazione permette l’upload di file attraverso form, diventa prioritario programmare il software affinché selezioni il contenuto caricato, sulla base della estensione prima di tutto (gli eseguibili potrebbero contenere exploit) e non lo vada ad eseguire automaticamente.
L’ENISA Threat Landscape Report del 2018 rileva come la code injection rappresenti ancora oggi il 51% degli attacchi alle applicazioni Web.
Broken Authentication
Un’altra minaccia spesso sottovalutata che incombe sulle applicazioni Web deriva da una non corretta gestione delle sessioni di autenticazione, quella che da OWASP viene definita Broken Authentication.
Nella fase di sviluppo del sistema di autenticazione è infatti necessario prestare una particolare attenzione a 3 fattori fondamentali:
- l’ID di sessione non deve essere visibile all’interno dell’URL perché potrebbe essere “sniffato” da un apposito software e riutilizzato dall’attaccante per instaurare una connessione autenticata;
- le password dovrebbero essere cifrate con un algoritmo forte (e meglio sarebbe se l’accesso fosse accompagnato da una seconda richiesta di autorizzazione, su un diverso canale, come l’SMS o la casella mail);
- il timeout della sessione non deve essere lungo, per impedire all’attaccante di approfittare dell’intervallo di tempo intercorrente tra la chiusura del browser (da parte dell’utente) e la scadenza della sessione legittima.
Sensitive Data Exposure
La mancata o la non adeguata cifratura dei dati contenuti, cioè la Sensitive Data Exposure, rappresenta la terza grande minaccia delle applicazioni Web.
Qualora infatti esista un’area di utenti registrati al sito, le informazioni ad essi afferenti, caratterizzate da profili di minore o maggiore confidenzialità, devono essere memorizzate da qualche parte, o all’interno di una base dati, oppure nel file system. Tali settori di archiviazione devono essere protetti:
- da un adeguato algoritmo di cifratura, nella fase statica di memorizzazione su disco;
- da un canale sicuro di comunicazione, nella fase dinamica di trasporto.
XXE – Entità Esterne XML
La quarta minaccia di cui parliamo, colpisce le applicazioni che processano, a qualsiasi livello, file XML.
Se infatti lo sviluppatore non ha provveduto a disabilitare, in tutti i parser XML dell’applicazione, il riferimento alle entità esterne, diventa possibile che l’attaccante riesca a comunicare con il processore XML, mal configurato o non aggiornato, inviandogli un input contenente un reference (ad esempio attraverso un link puntante ad una certa URL) connesso ad un vettore malevolo.
Broken Access Control
Una non corretta assegnazione dei privilegi di accesso alle risorse dell’applicazione rappresenta la quinta categoria di minacce, cui l’OWASP suggerisce di porre attenzione.
Broken Access Control, dunque, ci fa pensare ad una politica di controllo degli accessi non adeguatamente implementata.
La minaccia è tanto più importante quanto più ci si rende conto che i principali software che automatizzano la ricerca delle vulnerabilità si limitano a rilevare la presenza o assenza di un sistema di assegnazione/controllo degli accessi, ma non riescono a capire se questo sia effettivamente funzionante su tutto il perimetro delle risorse utilizzate.
Spesso, infatti, l’accesso a contenuti non pertinenti ad un certo profilo si scopre manualmente, manipolando l’URL con tecniche di parameter tampering, oppure attraverso test scrupolosi, condotti da un team specializzato che tenga conto di tutte le funzionalità (e, aggiungo, delle biforcazioni del flusso di esecuzione) del software.
Security Misconfiguration
La sesta categoria del framework, relativa alla non corretta configurazione di sicurezza, è forse quella più vicina all’intuizione dei non addetti al settore e al senso comune.
Security Misconfiguration vuol dire che certamente (e in via preliminare) un attaccante proverà a sfruttare tutti i difetti macroscopici del sistema, da quelli applicativi, come i difetti del codice (abbiamo accennato prima alla tecnica del parameter tampering, che sfrutta la manipolazione della query string ma i difetti possono anche essere logici, cioè legati ad una non corretta ingegneria del software) e la mancanza di patch, a quelli del layer di trasporto (pensiamo agli attacchi DDoS ad esempio che mirano ad esaurire le risorse delle infrastrutture di rete sovraccaricando di richieste gli apparati a livello di connessione TCP).
Tale categoria, per le ragioni suddette, appare a mio avviso trasversale al modello di OWASP, racchiudendo, come un “container residuale” tutti i vettori connessi ad una implementazione lontana dagli standard medi di sicurezza informatica (ad esempio, la mancata validazione degli input, l’utilizzo incosciente del metodo GET e dei dati in chiaro, l’ignorare la necessità del protocollo TLS, il non condurre la fase di test dell’applicazione ecc.).
XSS – Cross Site Scripting
Questa minaccia riguarda le applicazioni Web strutturate su un paradigma dinamico client/server ed è simile alla criticità che abbiamo analizzato al punto 1, quella delle injection.
Ciò che è importante sottolineare è che, mentre l’injection sfrutta tipicamente la debolezza del codice lato server, nel caso dell’XSS, l’inserimento da parte dell’attaccante di contenuto non voluto, si appoggia sui linguaggi lato client (Javascript è un esempio).
Il risultato è, come dicevo, analogo e consiste in una serie di conseguenze negative, tra cui:
- esecuzione di script malevolo, anche con tool di monitoraggio da remoto;
- possibilità di effettuare un redirect del browser su siti illeciti;
- capacità di iniettare “pezzi” di pagina Web non desiderati su cui innestare eventi;
- manipolazione e divulgazione di dati.
Enisa, nel suo Threat Landscape Report 2018, considera il Cross Site Scripting tra le “Top 5” nel 2018; la minaccia infatti continua ad occorrere nell’8% dei casi di attacco ad applicazioni Web, in tendenza stabile, rispetto al 2017 e ciò nonostante sia facilmente evitabile sia ex ante, attraverso l’utilizzo di funzioni di escape che neutralizzano i tag degli script, sia ex post, grazie alla facilità di detection da parte dei tool di penetration test.
Tecniche di de-serializzazione
Colpiscono quelle applicazioni che, nel tentativo di trasportare in rete oggetti complessi, ne encapsulano i componenti costituivi in entità, variabili appunto, serializzate, composte da quegli stessi elementi singoli, in serie, separati da caratteri sintatticamente significativi (una virgola, un tag ecc.).
La serializzazione può essere binaria o testuale. Quest’ultimo tipo, realizzabile anche con formati intrinsecamente vulnerabili come il Json o l’XML, è quello più frequentemente preso di mira dagli attaccanti i quali, intromettendosi nel processo di ricostruzione dell’informazione veicolata, possono comprometterne il contenuto.
Anche la minaccia della Insecure Deserialization può essere trattata ex ante, imponendo dei vincoli rigorosi all’oggetto ricostruito, oppure ex post tramite l’utilizzo di tool che monitorino l’integrità dei file.
Utilizzo di componenti con vulnerabilità conosciute
È una minaccia da non sottovalutare. Spesso, infatti, la gratuità di un contenuto o la sua facilità di utilizzo, possono indurre lo sviluppatore (o il committente) ad utilizzarlo nel proprio sistema anche a scapito della sicurezza.
È, inoltre, importante sottolineare che oggi lo sviluppo di applicazioni Web si avvale in buona parte di modelli o pattern preconfezionati, composti da una serie di plugin e librerie che raramente lo sviluppatore conosce nel dettaglio, sia nella loro individualità, sia nella interconnessione con gli altri componenti.
Per questo motivo risulta di primaria importanza partire da un buon progetto di ingegneria del software e passo passo analizzare tutte le funzionalità, anche con strumenti di analisi della composizione del software, effettuare test di vulnerabilità (anche manuali, consultando noti database delle vulnerabilità) ed eventualmente implementare gli aggiornamenti e le patch necessarie.
Insufficiente tracciatura e monitoraggio dei log applicativi
Costituisce l’ultima categoria della nostra rassegna: specialmente se il sistema comporta il trattamento di dati altamente impattanti (sia dal punto di vista aziendale che personale) e l’accesso ad esso da parte di una pluralità di soggetti con diversi livelli di privilegio, diventa necessario implementare un sistema di tracciatura degli eventi rilevanti (il logon e il logoff degli admin, la cancellazione o l’alterazione di una risorsa informativa, tenendo traccia delle operazioni di delete o di alter, l’insert di un’altra risorsa ecc.), degli errori di convalida degli input, tutte segnalazioni che possano darci informazioni in tempo reale ed anche fotografare lo stato del sistema in caso di incidenti.
Applicazioni Web: ecco come mitigare i rischi
Evitare di mettere a punto o trascurare questo tipo di monitoraggio costituisce di per sé una vulnerabilità, dal momento che impedirebbe, al committente e al responsabile dell’applicazione, la detection immediata della violazione e l’attivazione in tempo utile di tutti i meccanismi necessari per minimizzarla, sia da un punto di vista tecnico, attraverso l’innesco di procedure di incident recovery, sia dal punto di vista amministrativo/normativo, mi riferisco a questo proposito alla segnalazione di data breach, esponendo l’organizzazione ad impatti reputazionali ed economici.
NOTE
- La parametrizzazione, acquisendo ogni valore inserito dall’utente come parametro di una funzione e non come porzione di stringa, rende inefficaci le operazioni sintattiche di segmentazione della query o di validazione della stessa attraverso la logica booleana. ↑
