Sicurezza delle Applicazioni Web

Con la grandissima diffusione delle architetture distribuite, delle architetture orientate ai servizi e delle applicazioni web sono cresciuti esponenzialmente i problemi relativi alla sicurezza dei dati raccolti.
Essere pronta a resistere agli attacchi informatici e, soprattutto, mettere in atto misure preventive, è prerogativa di ogni software house; infatti, se un tempo il problema principale del raccogliere grandi quantità di dati era lo spazio fisico dove conservarli, oggi il più grave problema è mantenerli in sicurezza, cosicché non possano essere rubati o manomessi all’insaputa degli sviluppatori e soprattutto degli utenti finali.

Per quanto detto il requisito della sicurezza negli applicativi web rimane, ad oggi, uno dei principali problemi che affliggono questa tecnologia.
Molte delle vulnerabilità venute a galla a partire dagli anni 2000 sono da attribuire agli sviluppatori stessi, che, proprio a livello di codice sorgente, possono lasciare inconsapevolmente delle vulnerabilità sfruttabili da malintenzionati.

È altresì evidente che non esiste attualmente una soluzione unica atta a rendere il nostro sistema a prova di attacco e, citando una frase del fondatore di OWASP, Mark Curphey:

«Non esiste una bacchetta magica per la risoluzione dei problemi di sicurezza relativi alle applicazioni web. Quello che serve realmente è un ottimo team, molta esperienza, molto training e l’utilizzo di soluzioni allo stato dell’arte».

Oggigiorno l’aumento vertiginoso della concorrenza nello sviluppo software ha portato a ritmi di lavoro sempre più elevati, così che spesso l’approccio utilizzato dai developers è quello della “sicurezza a lavori fatti”: si tenta di capire se il software prodotto è sicuro solamente dopo averlo ultimato.
È decisamente più opportuno adottare un approccio “security first”, per cui l’attenzione alla sicurezza diventa parte integrante dello sviluppo di un sistema sin dalle fasi embrionali.

È proprio con lo scopo di evidenziare le principali debolezze dei software che nel settembre 2001 nasce la già citata Open Web Application Security Project (OWASP) che, avviata da Mark Curphey, Dennis Groves e Jeremiah Grossman, offre guide con consigli sulla creazione di applicazioni web sicure ed indicazioni per realizzare suite di test a cui sottoporre le applicazioni stesse.
Nella definizione di standard di sicurezza, OWASP propone una classifica (OWASP Top Ten) in cui vengono descritte le vulnerabilità più frequenti che affliggono i software esposti su internet.
In questo documento, in costante evoluzione, sono definiti in maniera ordinata (e categorizzate per entità del danno, frequenza di occorrenza, capacità tecniche necessarie dell’attaccante, ecc.) le criticità delle applicazioni, mirando a sensibilizzare sulla sicurezza delle applicazioni, identificandone alcuni dei rischi.
OWASP ha più volte pubblicato in passato la sua “Top 10” di attacchi contro le Web application, l’ultima revisione è stata rilasciata l’anno scorso a 3 anni dalla precedente.

TOP TEN VULNERABILITÀ

A1:2017-Injection

L’Injection è un tipo di vulnerabilità che può affliggere gli applicativi in grado di ricevere input dell’utente e che, conseguentemente, vanno ad interrogare un database.
Tali input possono venire sfruttati da utenti con un minimo di capacità tecnica, per effettuare interrogazioni non volute dallo sviluppatore e per eseguire codice malevolo.
Un attacco SQL injection prevede infatti l’inserimento di termini e caratteri SQL nei campi di un form al fine di ingannare l’applicazione, che invia così al database comandi diversi da quelli che invierebbe normalmente.
Per fare un esempio (tratto dal sito Web di OWASP), consideriamo il caso di una query di login costruita in questo modo:

select * from accounts
where username = ? and password = ?;

Questo specifico comando potrebbe essere inviato da un utente tramite un modulo presente su una pagina Web per recuperare le informazioni di un account dovendone inserire username e password.
Un malintenzionato potrebbe inserire nel modulo “‘name’ OR ‘x’=’x’” e, qualora l’applicazione non disponesse di difese adeguate contro attacchi di questo tipo, l’uso delle virgolette singole e del termine OR produrrebbero l’effetto di creare un comando SQL modificato, del tutto diverso da quello voluto dallo sviluppatore, che viene inviato al database:

select * from accounts
where username = ‘smith’ and password = ‘name’ OR ‘x’ = ‘x’;
A2:2017-Broken Authentication

Le funzioni dell’applicazione relative all’autenticazione e alla gestione delle sessioni sono spesso implementate in modo errato, consentendo agli aggressori di compromettere password, chiavi o token di sessione o di sfruttare altri difetti di implementazione per assumere temporaneamente o permanentemente le identità di altri utenti.
Basti pensare ai famosi cookie, che servono per consentire all’utente di navigare nelle pagine web senza dover ogni volta rieseguire la login; quando utilizziamo questi ultimi dobbiamo prestata particolare attenzione ad invalidarli in un lasso di tempo ragionevole, dopo il logout e soprattutto a richiedere le credenziali di accesso per effettuare operazioni particolarmente delicate (es. accedere ai metodi di pagamento, cambiare informazioni dell’account ecc.).
Questi sono alcuni punti deboli che possono consentire di acquisire o ignorare i metodi di autenticazione utilizzati da un’applicazione Web:

– Le credenziali di autenticazione dell’utente non sono protette quando memorizzate.
– Le credenziali di accesso sono prevedibili.
– Gli ID di sessione sono esposti nell’URL

A3:2017- Esposizione di dati sensibili

L’esposizione di dati sensibili può verificarsi quando controlli di sicurezza come HTTPS non vengono implementati correttamente, lasciando così agli hacker la possibilità di rubare informazioni sensibili come password, informazioni di pagamento, ID, indirizzi ecc.
Si tratta quindi di una vulnerabilità a livello di trasporto dei dati e gli effetti sono molto simili alla falla precedentemente trattata (Broken authentication).
È un tipo di attacco molto diffuso poiché è facilmente attuabile, spesso è possibile semplicemente monitorando il traffico della rete per rubare cookie di sessione o intercettare altre informazioni sensibili non correttamente criptate.

Come prevenire:
– Criptare i dati durante il trasporto e a riposo.
– Evitare di memorizzare e/o trasferire informazioni sensibili se non strettamente necessario.
– Usare gli ultimi algoritmi di criptaggio.
– Disabilitare il completamento automatico su moduli che raccolgono dati.
– Disabilitare la memorizzazione nella cache di moduli che raccolgono dati.

A4:2017-XML External Entities (XXE)

XML External Entity (XXE) si riferisce a un tipo specifico di attacco SSRF (Server-side Request Forgery), grazie al quale un utente malintenzionato può causare Denial of Service (DoS) o accedere a file e servizi.
Nel caso in cui un’applicazione Web accetti come input documenti XML inviati dall’utente, quest’ultimo potrebbe crearne uno tale da provare ad accedere a risorse del filesystem.
Inoltre, caricando un flusso di dati infiniti, un utente potrebbe essere in grado di consumare tutte le risorse di un sistema, negando l’accesso ad altri utenti e provocando il malfunzionamento del server stesso.
In alcuni rari casi, potrebbe essere addirittura possibile eseguire codice in remoto caricando codice eseguibile (come PHP); è successo nel 2016, quando un ingegnere brasiliano ha utilizzato un attacco XXE per ottenere l’esecuzione di codice in modalità remota contro Facebook.

A5:2017-Broken Access Control

Le restrizioni su ciò che gli utenti autenticati sono autorizzati a fare spesso non vengono applicate correttamente.
Gli aggressori possono sfruttare questi difetti per accedere a funzionalità e/o dati non autorizzati come l’accesso tramite account di altri utenti, la visualizzazione di file sensibili, la modifica dei dati di altri utenti, la modifica dei diritti di accesso, ecc.
Il controllo degli accessi è il modo in cui un’applicazione Web concede l’accesso a contenuti e funzionalità ad alcuni utenti e non ad altri. Questi controlli vengono eseguiti dopo l’autenticazione e regolano ciò che gli utenti autorizzati possono fare.
Il controllo degli accessi sembra un problema semplice ma è insidiosamente difficile da implementare correttamente ed è strettamente legato al contenuto e alle funzioni fornite dal sito stesso.
Gli sviluppatori spesso sottovalutano la difficoltà di implementare un meccanismo affidabile di controllo degli accessi. Molti di questi schemi non sono stati progettati deliberatamente, ma si sono semplicemente evoluti insieme al sito web. In questi casi, le regole di controllo dell’accesso vengono inserite in varie posizioni su tutto il codice rendendo il tutto sempre più di difficile comprensione per le successive implementazioni dello sviluppatore e quindi sempre più soggetto a falle.

A6:2017- Errori nelle configurazioni di sicurezza

Le errate configurazioni del nostro programma in merito alla sicurezza sono tra i bersagli preferiti dagli hacker, poiché sono una delle tipologie di falle più diffuse e che richiedono meno conoscenze tecniche per effettuare un attacco.
Una delle principali vulnerabilità consiste in configurazioni errate per quanto riguarda lo stack degli errori.
Questi ultimi, se configurati in maniera impropria, potrebbero dare informazioni sensibili a video come righe di codice contenenti il nome del database, la stringa di connessione, i login a servizi esterni, ecc. e di conseguenza dare gli strumenti necessari per un attacco.

Alcuni dei problemi relativi alle configurazioni possono essere:
– Visualizzazione dello stack degli errori.
– Debug abilitato.
– Autorizzazioni di cartella errate.
– Utilizzo di account o password predefiniti.
– Pagine di configurazione abilitate.

A7:2017- Cross-Site Scripting (XSS)

XSS consente agli aggressori di iniettare script sul lato client in pagine Web e, in molti casi, può essere utilizzato per superare i controlli di accesso.
I difetti XSS si verificano ogni volta che un’applicazione include dati non attendibili in una nuova pagina Web senza convalida corretta.
Generalmente una vulnerabilità XSS consiste nell’inclusione di codice html all’interno di una pagina web per effettuare operazioni malevole, come ad esempio prelievo di cookies privati.

Esistono 2 tipi principali di attacchi XSS:
Reflected (non persistente): è di gran lunga il tipo più comune.
Questi buchi si presentano quando i dati forniti da un client Web (più comunemente nei parametri di query HTTP) vengono utilizzati immediatamente dagli script lato server per analizzare e visualizzare una pagina di risultati per quell’utente, senza una corretta validazione della richiesta.
Persistent: è una variante più devastante di un difetto di scripting cross-site: si verifica quando i dati forniti dall’hacker vengono salvati sul server (generalmente su di un database) e quindi visualizzati in modo permanente su pagine “normali” restituite anche ad altri utenti nel corso della normale navigazione. Un classico esempio di pagine con questo rischio sono le bacheche o i forum online in cui gli utenti sono autorizzati a postare messaggi formattati in HTML per altri utenti.

A8:2017- Deserializzazione insicura

Iniziamo analizzando cosa sono la serializzazione e la deserializzazione:

– Il termine ‘serializzazione’ si riferisce a un processo di conversione di un oggetto in un formato che può essere persistito su disco (ad esempio salvato in un file o in un archivio dati). Il formato in cui viene serializzato un oggetto può essere sia binario che testuale. JSON e XML sono due dei formati (testuali) di serializzazione più comunemente usati nelle applicazioni web.
– La deserializzazione, d’altra parte, è l’opposto della serializzazione, ovvero la trasformazione di dati provenienti da un file o stream in una struttura in memoria.

Le applicazioni web utilizzano regolarmente la serializzazione e la deserializzazione, e la maggior parte dei linguaggi di programmazione fornisce anche funzionalità native per serializzare i dati (in particolare in JSON e XML); infatti è importante capire che la deserializzazione sicura degli oggetti è una pratica normale nello sviluppo del software.
Tuttavia, è possibile si utilizzi tale funzionalità tramite libreria esterna, o addirittura fatta “a mano dallo sviluppatore” ed è proprio in questi casi che nascono i principali e più diffusi problemi.
Due dei principali pericoli nei quali si rischia di incorrere sono gli attacchi DoS (Denial of Service) e l’esecuzione di codice in modalità remota.
Il primo ha come principale conseguenza quella di portare un disservizio da parte dell’applicativo, che (a seconda della natura di business dello stesso, dalla mole di informazioni trasmesse e dal numero di utenti) può avere conseguenze più o meno gravi.
Il secondo è un caso più raro, poiché dipendente strettamente dal linguaggio utilizzato per lo sviluppo del software, ma è sicuramente uno dei peggiori scenari che possano capitare ad uno sviluppatore. La possibilità di eseguire codice malevolo direttamente dall’applicativo può dare possibilità praticamente illimitate all’attaccante, che, nella peggiore delle ipotesi, potrebbe essere in grado di accedere ai dati persistiti sul nostro database, rubare credenziali di accesso ai server, o danneggiare i server stessi irrimediabilmente cancellando file di sistema.
Quelli che seguono sono alcuni consigli (direttamente dal “Cheat Sheet” di OWASP) per poter prevenire e far fronte in maniera efficace a problemi di deserializzazione:
– Validare input degli utenti.
– Non accettare oggetti serializzati da fonti non attendibili.
– Il processo di serializzazione deve essere crittografato.
– Eseguire il codice di deserializzazione con autorizzazioni di accesso limitato (così da negare accesso a risorse o esecuzione di codice).
– Utilizzare un firewall in grado di rilevare la deserializzazione dannosa o non autorizzata.

A9:2017- Usare componenti con vulnerabilità note

È importante capire che i componenti, come librerie, framework e altri moduli software, per quanto generalmente sviluppati da persone molto competenti, sono affetti dagli stessi problemi che affliggono il nostro codice.
Applicazioni e API che utilizzano componenti con vulnerabilità note possono minare le loro difese e consentire vari tipologie di attacchi; in particolar modo i componenti open source presi dalla community meritano molta attenzione e cautela nel loro utilizzo.
È sempre buona norma documentarsi bene in merito ai componenti esterni che siamo decisi ad utilizzare nelle nostre applicazioni, effettuare costantemente gli aggiornamenti (soprattutto se di sicurezza) ed eventualmente essere pronti a farne a meno e rimpiazzarli se si riscontrano vulnerabilità note.

A10:2017- Logging e Monitoring insufficiente

Si verifica quando gli eventi critici per la sicurezza non vengono registrati correttamente e il sistema non sta monitorando gli eventi in maniera esaustiva.
Innegabilmente, la mancanza di queste funzionalità può rendere più difficili da rilevare le attività malevole e influisce negativamente sulla gestione efficace degli incidenti quando si verifica un attacco.
Quando un malintenzionato riesce ad effettuare attacchi come interrogazioni del database, modifiche delle configurazioni, ecc. è molto difficile per le organizzazioni rilevare ciò che è realmente accaduto e l’assenza di un monitoraggio dettagliato dell’accaduto fa sì che i tempi di ripristino del sistema si dilatino notevolmente.
Una registrazione dettagliata dell’accesso degli utenti e delle informazioni alle quali attingono è diventato un elemento fondamentale per proteggere le risorse memorizzate.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *