La presentazione parla di sicurezza informatica, con un focus importante su rischi/opportunità per le startup che lavorano in ambito digital. Si esamina il contesto in cui ci troviamo attualmente, valutando le ragioni per cui la sicurezza informatica è importante, non solo a processo finito, ma già nell'implementazione del proprio progetto, e, sopratutto, quali potrebbero essere i danni causati da attacchi di questo tipo. In più, si sfatano alcuni falsi miti che sono stati costruiti nel tempo attorno a questa tematica, facendo un po' di chiarezza sull'argomento, ed esaminando le principali problematiche e le soluzioni per prevenirle, che affliggono le applicazioni web e mobile.

1. Security by Design
Treatabit - Torino, 24 Gennaio 2019

2. _ ABOUT
▪ Founder & CEO @ BeDefended
▪ Laurea Magistrale in Ingegneria Informatica
▪ CCSK, GWAPT, Comptia Security+, CCNA
▪ Co-autore OWASP Testing Guide v4
▪ Bug Bounty Hunter nel tempo libero
Davide Danelon
2

3. 3
_ AGENDA
▪ Introduzione e Contesto
▪ Leggende e falsi miti
▪ I principali rischi per le startup
▪ Pillole di Web e Mobile Application Security
▪ Startup Checkup Program
▪ Q & A
18:15
/
20:00
Security by Design
3

4. 4
_ INTRODUZIONE
Contesto
4
L'importanza dei dati è sottolineata dal progressivo aumento di
attacchi informatici volti al loro furto, distruzione o manomissione.
53.308
Incidentidisicurezza
2.216
DataBreach
65
Paesicoinvolti
2017
Fonte:2018DataBreach
InvestigationsReport
77 %
23 %
attacchi provenienti dall'esterno
attacchi provenienti dall’interno
3,0 mil/€ Costototalemediodi
violazionedeidati + 12 %
134 € Costomedioper
recordpersiorubati + 11 %
* In base allo studio condotto dal Ponemon Institute – ‘2018 Cost of Data Breach Study’
condotto su 26 società italiane in 17 diversi settori di business
3,9 mil/$ Costototalemediodi
violazionedeidati
148 $ Costomedioperrecord
persiorubati
* In base allo studio condotto dal Ponemon Institute – ‘2018 Cost of Data Breach Study’ condotto su
477 organizzazioni in 13 paesi diversi e due regioni
Situazione Internazionale* Situazione Italiana*
+ 6,4 %
+ 4,8 %

5. 5
_ INTRODUZIONE
Costi relativi delle remediation
5
Source: IBM System Science Institute Relative Cost of Fixing Defects
1
6,5
15
100
Design Implementation Testing Maintenance

6. 6
_ STARTUP (IN)SECURITY
▪ Phishing e Social Engineering: fenomeno in crescita, in particolare lo spear phishing, forma
mirata di phishing, in cui le email sembrano provenienti da qualcuno che il destinatario
conosce e di cui si fida.
I principali rischi per le Startup
6
▪ Attacchi Distributed Denial of Service (DDoS): hanno reso inaccessibili per
periodi di tempo considerevoli alcuni tra i siti più visitati al mondo.
▪ Malware: software installato su un dispositivo per eseguire task indesiderati a beneficio di una
terza parte. I ransomware sono l’ultima “moda”, ma ne esistono altri come: spyware, virus e
trojans.

7. 7
_ STARTUP (IN)SECURITY
▪ Dispositivi non patchati: Dispositivi di rete, server, stampanti che utilizzano software o firmware
vulnerabile che non è stato patchato.
I principali rischi per le Startup
7
▪ BYOD: dispositive personali non sicuri espongono più facilmente a furto e
perdita di dati
▪ Application vulnerabilities: applicazioni web e mobile sono spesso alla base dei servizi offerti
dale startup. Applicazioni non sufficientemente sicure possono aprire la strada ai cyber
criminali.

8. 8
_ CYBER SECURITY
1. Motivazioni economiche e di business
▪ Analisi dei costi
▪ Valutazione dei rischi
2. Motivazioni legali o normative
▪ GDPR
▪ PCI DSS
3. Motivazioni strategiche
▪ Orientamento Strategico
Perché è fondamentale la Sicurezza
8

9. 9
_ CYBER SECURITY
La stima dell’impatto di un eventuale attacco è legata anche ai danni che l’evento è in grado di produrre.
I danni si possono classificare in:
▪ DIRETTI: es. cancellazione, modifica o furto di dati (proprietà intellettuale, ecc.)
▪ INDIRETTI: mancata o ritardata fatturazione e/o riscossione dei crediti, pagamento di multe, penali e/o danni a terzi
▪ CONSEQUENZIALI: permangono anche a seguito del ripristino (es. danni di immagine o pubblicità negative, contenzioso con
clienti e fornitori
Impatto e danni
9

10. 11
_ CYBER SECURITY
1. La mia applicazione è servita su HTTPS quindi è sicura
▪ Numerose vulnerabilità: Heartbleed, DROWN, POODLE, BEAST
▪ Connessione “sicura” tra client e server → il client potrebbe essere l’attaccante stesso
2. I cybercriminali mirano soprattutto alle grandi aziende
▪ Grande azienda → più soldi → più investimenti in sicurezza, PMI → meno soldi → meno investimenti in sicurezza → target più semplice
▪ Target anche di attacchi tramite sistemi automatizzati
Falsi miti sulla Sicurezza
11

11. 12
_ CYBER SECURITY
3. I programmi e servizi di sicurezza costano troppo
▪ Soluzioni e risorse open source e gratuite: ModSecurity, OWASP resources (e.g. ZAP, checklists, ESAPI etc.), OpenVAS, SonarQube, Ansible
▪ Che valore dai al tuo business? Un solo attacco potrebbe compromettere l’intero business
4. Ho antivirus e firewall quindi sono sicuro
▪ Gli antivirus non prevengono nessuna delle vulnerabilità presenti nella OWASP Top 10
▪ Firewall network classico non prevenie attacchi “web-based”
Falsi miti sulla Sicurezza
12

12. 13
_ CYBER SECURITY
5. La sicurezza è responsabilità solo dell’IT
▪ Phishing e social engineering
▪ Chiunque abbia accesso a dati sensibili/confidenziali e/o funzioni privilegiate potrebbe esporre la startup a rischi
6. Faccio backup periodico quindi sono sicuro
▪ Vulnerabilità non risolte possono essere sfruttate nuovamente
▪ Ritardi nella rilevazione degli attacchi potrebbero aver ormai compromesso parte del business
Falsi miti sulla Sicurezza
13

13. WEB APPLICATION SECURITY
14

14. Web Application Security
0001
* Rischi
▪ Informazioni rivelata dall’applicazione potrebbero essere sfruttate da attaccanti per portare a termine attacchi
mirati.
▪ Informazioni utili agli attaccanti includono, per esempio: versioni di framework, librerie, middleware e sistema
operativo.
Information Gathering
15
* Prevenzione in “pillole”
✓ Rivedere le configurazioni di tutto lo stack in maniera che non rivelino informazioni sulla versione.
✓ Analizzare il codice in maniera tale che non vi siano informazioni, non necessarie, esposte.

15. Web Application Security
0002
* Rischi
▪ Vulnerabilità (solitamente note agli attaccanti) legate a:
▪ Configurazioni non sicure dei framework o delle librerie utilizzate
▪ Librerie o più in generale software non aggiornato (o non supportato)
Configuration Management
16
Esempi Famosi
Equifax ha subito un data
breach nel 2017, a causa di
una versione non aggiornata
di Apache Struts, costato
circa 240 milioni di dollari e
che ha coinvolto circa 147
milioni di persone.
* Prevenzione in “pillole”
✓ Verificare la documentazione del software utilizzato in modo da configurarlo in maniera
sicura
✓ Mantenere tutto il software aggiornato

16. Web Application Security
* Rischi
▪ Le problematiche di implementazione delle funzioni di autenticazione potrebbe permettere ad
un attaccante di accedere a dati riservati.
▪ Password deboli o di default sono un esempio di problematiche, legate all’autenticazione,
facili da sfruttare.
Authentication & Identity
17
0003
Esempi Famosi
Nel 2018 configurando il
cookie “username=admin”
era possibile accedere con
privilegi amministrativi
sull’interfaccia web dei NAS
WD.
* Prevenzione in “pillole”
✓ Implementare una password policy robusta ed autenticazione a due fattori.
✓ Porre particolare attenzione alle funzioni che gestiscono l’autenticazione ed il recupero delle
credenziali.

17. Web Application Security
* Rischi
▪ Accesso non autorizzato a dati di altri utenti attraverso privilege escalation orizzontali
▪ Accesso non autorizzato a dati o funzioni amministrative attraverso privilege escalation
verticali
Authorization
18
0004
Esempi Famosi
Nel 2011, a causa di un
IDOR, era possibile accedere
alle foto di utenti arbitrari
(scattate con la webcam) ed
inviate su Facebook tramite
messaggi privati.
Nel 2018, una vulnerabilità
sulla funzionalità “View As”
di Facebook ha consentito
la potenziale
compromissione di 50
milioni di account.
* Prevenzione in “pillole”
✓ Definire una matrice di controllo degli accessi
✓ Verificare che l’accesso ai dati ed alle funzioni sia ristretto secondo lo schema autorizzativo
definito

18. Web Application Security
* Rischi
▪ Impersonificazione di utenti arbitrari in caso di implementazione debole della sessione
▪ Un attaccante potrebbe forzare un utente vittima ad effettuare azioni dispositive senza il
proprio volere.
Session Management
19
0005
Esempi Famosi
Nel 2010 Twitter fu vittima
di un worm che, sfruttando
un CSRF, si è propagato sui
profili degli utenti.
* Prevenzione in “pillole”
✓ Utilizzare meccanismi di gestione della sessione standard
✓ Utilizzare token non predicibili, legati alla sessione, inviandoli tramite parametri e/o header
custom

19. Web Application Security
* Rischi
▪ Esecuzione di codice, comandi o query arbitrarie dovute all’invio di dati non validati ad un
interprete
▪ Ogni fonte di dato controllabile da un attaccante può diventare un vettore d’iniezione come
per esempio parametri, header, servizi web interni/esterni.
Input Validation
20
0006
Esempi Famosi
450.000+ account Yahoo
violati tramite SQL injection
nel 2012.
Sempre tramite SQL
Injection dati sensibili e
confidenziali della Sony
furono rubati nel 2011.
* Prevenzione in “pillole”
✓ Utilizzare funzioni e API sicure che permettano di disaccoppiare l’input dell’utente dalle
query/comandi (es. query parametrizzate).
✓ Effettuare input validation (preferibilmente basata su whitelist)
✓ Effettuare output encoding

20. Web Application Security
* Rischi
▪ La mancanza di una corretta gestione degli errori potrebbe fornire informazioni utili ad un
attaccante sul funzionamento dell’applicativo (es. tramite stacktrace)
▪ Errori applicative potrebbero facilitare lo sfruttamento di altre vulnerabilità (es. SQL injection)
Error Handling
21
0007
Esempi Famosi
Nel caso del Padding Oracle
su .NET i differenti errori
restituiti vengono sfruttati
per decifrare stringhe senza
conoscere la chiave.
* Prevenzione in “pillole”
✓ Gestire tutti gli errori e le eccezioni possibilmente in maniera centralizzata
✓ Visualizzare all’utente solo errori generici e tracciare il dettaglio solo nei log

21. Web Application Security
* Rischi
▪ Il mancato utilizzo di funzioni crittografiche potrebbe esporre dati sensibili e confidenziali ad
eventuali attaccanti
▪ L’utilizzo di funzioni crittografiche deprecate o chiavi di cifratura deboli potrebbe inficiare la
confidenzialità dei dati
Cryptography
22
0008
Esempi Famosi
Nel 2012 LinkedIn è stato
vittima di un attacco che ha
portato alla
compromissione di 6.5
milioni di account.
Gli hash delle password
sono stati crackati a causa
dell’utilizzo di algoritmi
deboli (unsalted SHA-1).* Prevenzione in “pillole”
✓ Utilizzare librerie e funzioni crittografiche standard
✓ Utilizzare chiavi di cifratura robuste

22. Web Application Security
Transport Security
23
0009
Esempi Famosi
Nel 2014, quando è stato
reso noto l’attacco POODLE,
quasi il 97% dei siti web
contenuti nella Alexa Top 1
million, si è rivelato essere
potenzialmente vulnerabile.
* Rischi
▪ Applicazioni servite su canale non sicuro (HTTP) sono prone ad attacchi di tipo Man in The
Middle (MiTM)
▪ La non corretta configurazione di HTTPS potrebbe comunque consentire attacchi MiTM.
* Prevenzione in “pillole”
✓ Assicurarsi che l’applicazione sia servita esclusivamente su canale sicuro (HTTPS)
✓ Configurare in maniera corretta TLS

23. Web Application Security
* Rischi
▪ Bypass o abuso delle funzioni legate alla logica applicativa
▪ Problematiche legate ad un design non sicuro potrebbero essere particolarmente difficili da
risolvere poichè legate all’architettura applicative.
Business Logic & Application DoS
24
0010
Esempi Famosi
Nel 2017 è stata individuata
una vulnerabilità legata alla
logica applicativa di Uber,
che poteva permettere di
bypassare il pagamento ed
effettuare viaggi gratis.
* Prevenzione in “pillole”
✓ Porre particolare attenzione alla fase di design, individuare funzionalità potenzialmente
soggette ad “abuso” ed effettuare un’attività di threat modelling
✓ Implementare livelli differenti di controlli (principio della “defense in depth”) e limiti sull’utilizzo
delle funzionalità

24. Web Application Security
* Rischi
▪ Presenza di vulnerabilità sul codice eseguito lato client (es. JavaScript)
▪ Lo sfruttamento di problematiche lato client potrebbe talvolta non essere tracciato all’interno
dei log applicativi
Client Side
25
Esempi Famosi
Nel 2016 è stata individuate
una problematica legata al
CORS sugli IDE JetBrains
che permetteva l’accesso a
file arbitrari sulla macchina
della vittima.
* Prevenzione in “pillole”
✓ Effettuare input validation e output encoding dei dati trattati dal codice lato client
✓ Verificare le origini delle richieste e configurare gli opportuni header
0011

25. MOBILE APPLICATION
SECURITY
26

26. Mobile Application Security
0001
* Rischi
▪ I dati memorizzati localmente possono essere accessibili ad applicazioni terze ed attaccanti.
▪ I dati sensibili e confidenziali memorizzati potrebbero essere accessibili a chiunque anche in
caso di dispositivo perso.
Local Data Storage
27
Esempi Famosi
Nel 2018 è stato scoperto
un nuovo vettore di attacco,
nominato Man-in-the-Disk,
che sfrutta la mancata
protezione dei dati scritti
dalle app Android sulla
memoria esterna. Tra le
applicazioni soggette anche
alcune sviluppate da Google
stessa.
* Prevenzione in “pillole”
✓ Minimizzare la memorizzazione dei dati sensibili e confidenziali sul dispositivo
✓ Cifrare e proteggere da accesso non autorizzato tutti i dati confidenziali memorizzati

27. Mobile Application Security
0002
* Rischi
▪ App che effettuano connessioni su canale non sicuro (HTTP) sono prone ad attacchi di tipo
Man in The Middle (MiTM)
▪ La mancanza di Certificate Pinning potrebbe comunque consentire attacchi MiTM.
Transport Security
28
Esempi Famosi
A causa di una vulnerabilità
nella libreria AFNetworking,
scoperta nel 2015, le
applicazioni iOS che la
utilizzavano erano
potenzialmente soggette ad
attacchi MiTM.
* Prevenzione in “pillole”
✓ Assicurarsi che l’applicazione contatti il backend esclusivamente su canale sicuro (HTTPS)
✓ Implementare, ove possibile, il Certificate Pinning

28. Mobile Application Security
* Rischi
▪ Le leakage di informazioni dovuti a:
▪ problematiche dei framework o delle librerie utilizzate
▪ funzionalità del sistema operativo non considerate
Unintended Data Leakage
29
0003
Esempi Famosi
Nel 2013 l’applicazione
mobilde di Facebook per
Android esponeva l’access
token, in chiaro, all’interno
dei log. Applicazioni terze,
installate sul device,
potevano pertanto rubare il
contenuto e consentire di
impersonare l’utente vittima.* Prevenzione in “pillole”
✓ Prevenire che informazioni sensibili e confidenziali vengano incluse nei log, nella cache o più
in generale siano accessibili a funzionalità terze.
✓ Effettuare analisi delle funzioni esposte dalle librerie utilizzate e dal sistema operativo

29. Mobile Application Security
* Rischi
▪ L’utilizzo di funzioni crittografiche deprecate o chiavi di cifratura deboli potrebbe inficiare la
confidenzialità dei dati
▪ L’utilizzo di funzioni di hash deprecate potrebbe inficiare la sicurezza delle funzionalità per le
quali sono utilizzate
Cryptography
30
0004
Esempi Famosi
Le vecchie versioni di
WhatsApp cifravano il
database dei messaggi con
la medesima chiave di
cifratura.
Su Android, chiunque
avesse accesso al
dispositivo poteva scaricare
il file dalla memoria esterna
e decifrarlo facilmente.
* Prevenzione in “pillole”
✓ Utilizzare librerie e funzioni crittografiche standard
✓ Utilizzare chiavi di cifratura robuste

30. Mobile Application Security
* Rischi
▪ Interazione da parte di applicazioni terze installate sul device potrebbe portare a
comportamenti non previsti
▪ Problematiche legate al mancato controllo sugli accessi (es. Permission Re-Delegation, URL
Schema Hijacking)
Inter-Process Communication
31
0005
Esempi Famosi
Il “Power Control Widget” su
Android poteva essere
sfruttato da applicazioni
terze per abilitare
funzionalità permesse alle
sole app di Sistema.
Su vecchie version di Skype
per iOS era possible forzare
l’utente vittima ad effettuare
chiamate arbitrarie
automaticamente con un
link tramite l’URL schema
“skype://”
* Prevenzione in “pillole”
✓ Validare gli input ricevuti
✓ Avvertire utente prima di effettuare azioni dispositive
✓ Limitare l’esposizione di componenti ad applicazioni terze

31. Mobile Application Security
* Rischi
▪ Esecuzione di codice, comandi o query arbitrarie dovute all’invio di dati non validati ad un
interprete
▪ Ogni fonte di dato controllabile da un attaccante può diventare un vettore d’iniezione come
per esempio parametri, header, servizi web interni/esterni.
Input Validation
32
0006
Esempi Famosi
Nel 2013 è stata scoperta la
possibilità di eseguire
codice arbitrario su
applicazioni Android tramite
l’iniezione di codice
JavaScript all’interno di una
WebView.
Secondo un’analisi condotta
il 57% delle top 1000 apps
erano potenzialmente
vulnerabili.
* Prevenzione in “pillole”
✓ Utilizzare funzioni e API sicure che permettano di disaccoppiare l’input dell’utente dalle
query/comandi (es. query parametrizzate).
✓ Effettuare input validation (preferibilmente basata su whitelist)
✓ Effettuare output encoding

32. Mobile Application Security
* Rischi
▪ Un attaccante potrebbe venire a conoscenza delle logiche applicative e di eventuali dati
contenuti nel codice, disassemblando e decompilando le app mobile.
▪ Un attaccante potrebbe modificare il comportamento dell’app tramite tampering
Code Protection
33
0007
Esempi Famosi
Versioni modificate di
applicazioni bancarie e/o di
giochi vengono
giornalmente rilasciate.
Inoltre alcuni malware
sfruttano i permessi di
root/jailbreak per interagire
con le applicazioni target.* Prevenzione in “pillole”
✓ Evitare di include chiavi e informazioni private all’interno del codice sorgente
✓ Offuscare il codice in fase di compilazione
✓ Implementare meccanismi anti-tampering

33. Mobile Application Security
* Rischi
▪ Il backend (es. API) può essere contattato direttamente da un attaccante, bypassando
eventuali controlli implementati lato client
▪ Il client, essendo sotto il controllo dell’utente, potrebbe essere stato compromesso
Backend Security
34
0008
Esempi Famosi
Nel 2018 una vulnerabilità
sulle API di Google+ ha
esposto informazioni sul
profilo di circa 52 milioni di
utenti, anche per profili
configurati come privati.
* Prevenzione in “pillole”
✓ Applicare le principali regole per la protezione del backend di applicazioni web

34. «STARTUP CHECKUP PROGRAM»
35

35. 36
CLOUD SECURITY SECURITY ASSESSMENT
TRAINING CONSULTING
BeDefended
Comprehensive solutions to
protect applications and data
in the cloud.
Web and Mobile trusted
Security Assessment.
Training and awareness on
Application and Cloud Security.
Tailor-made Services and
Support to secure your
business.

36. 38
_ STARTUP CHECKUP PROGRAM
Offering
38
0
0
80+
COSTI FISSI
Si paga solo per le vulnerabilità individuate
con un cap di spesa massima
CATEGORIE DI VULNERABILITA’
Analisi comprende tutte le principali
problematiche incluse nella OWASP Top
10 nonchè le più recenti vulnerabilità
FALSI POSITIVI
Analisi manuale del target comprensiva di
Proof of Concept 1
FOLLOW-UP e RETEST
Assistenza nella remediation e 1 retest
delle vulnerabilità individuate incluso

37. Grazie per l’attenzione
39

38. Many businesses around the world are
attacked everyday.
DON’T BE LIKE THEM.
BEDEFENDED.
@TwiceDi
@TwiceDi
davide.danelon