Il documento discute la sicurezza delle applicazioni web, esplorando le vulnerabilità, i principi principali della sicurezza informatica e le metodologie OWASP. Viene evidenziata l'importanza della gestione del rischio e la classificazione delle vulnerabilità, oltre a fornire informazioni su standard e pratiche per minimizzare i rischi nel ciclo di vita dello sviluppo software. Si conclude con una panoramica sulle vulnerabilità più comuni e le tecniche di sfruttamento, enfatizzando la necessità di un approccio proattivo alla sicurezza.

1. CLOUD
CONFERENCE
ITALIA
2019

2. SPONSOR

3. WHO AM I?
Mirko Strozzi
IT Manager & Digital Manager
Ergon srl
walk2talk srl
Mirko Strozzi
mirko.strozzi@ergongroup.it
mirko.strozzi@walk2talk.it

4. AGENDA
La Sicurezza nelle Web Applications
Metodologie OWASP
OWASP Top 10
DEMO

5. SICUREZZA
NELLE WEB
APPLICATIONS

6. MERCATO DI
RIFERIMENTO
 Le vulnerabilità applicative
vengono continuamente
introdotte dagli stessi team di
sviluppo interni alle aziende,
dai fornitori, dalle soluzioni
open-source: alcuni analisti
affermano che il 64% degli
sviluppatori non sono
confidenti di poter scrivere
applicazioni sicure (fonte:
Microsoft Developer
Research);
Fonte ClusIT - 2019

7. QUANTO COSTA CORREGGERE I PROBLEMI?

8. CENNI STORICI
La pratica di sviluppare applicazioni software capaci di operare
correttamente anche in condizioni di attacco da parte di agenti
di minaccia esterni viene definita Software Security.
Il primo libro e testo accademico ad esprimersi sull’argomento
apparve nel 2001 e fu una chiara dimostrazione dell’ interesse e
dello studio della tematica da parti di sviluppatori, software
architect ed esperti di sicurezza informatica la cui attenzione
fino a quel momento rimaneva concentrata su firewall, intrusion
detection e sistemi antivirus.
Una vera e propria rivoluzione di pensiero quindi.
Il testo si chiamava Building Secure Software.

9. CENNI STORICI
La comunità blackhats, nel contempo, percepì la reale
possibilità di portare con successo attacchi informatici alle
applicazioni.
Da qui la contrapposizione con i whitehats e l’inizio della
diffusione delle prime e fondamentali best practices in
materia di sicurezza applicativa, le prime tra tutte
riconducibili ad una buona ingegnerizzazione del software,
una piena comprensione delle minacce più comuni,
compresi i difetti propri dei linguaggi di programmazione,
ma soprattutto una considerazione della problematica fin
dalle prime fasi del ciclo di sviluppo.

10. I PRINCIPI
La Sicurezza Informatica consiste in un insieme di misure di
carattere organizzativo, tecnologico e procedurale mirate a
garantire 3 principi fondamentali:
 Segretezza/Confidenzialità: le informazioni possono
essere lette solo da chi ne ha diritto.
 Integrità: le informazioni possono essere modificate solo
da chi ne ha diritto.
 Disponibilità: una risorsa deve essere disponibile quando
richiesta.

11. GESTIONE DEL
RISCHIO
La gestione del rischio informatico si svolge attraverso un articolato processo che mira a
identificare le vulnerabilità del sistema, le possibili minacce e la relativa probabilità di
accadimento nonché a stimare i potenziali danni.
Il rischio è calcolato in funzione di 3 fattori:
 Minacce o Threat: è una potenziale causa di incidente che può danneggiare uno
o tutti i beni del patrimonio informativo
 Impatto: rappresenta il danno effettivo e gli effetti collaterali dell'incidente
 Vulnerabilità: rappresenta un difetto nella progettazione, nell’implementazione
di un componente o nei controlli di sicurezza del sistema che può essere
sfruttata, intenzionalmente o meno, da un attaccante, per violare il sistema.
Le vulnerabilità quindi non compromettono un sistema, ma se utilizzate da una
minaccia possono dar luogo ad un evento indesiderato.

12. CLASSIFICAZIONE
DELLE
VULNERABILITÀ
Non esiste una classificazione univoca delle vulnerabilità, essa dipende dal tipo di
analisi che si vuole condurre, ovvero dall'ambito di applicazione. Per quanto riguarda i
sistemi informatici, le vulnerabilità si possono presentare a qualsiasi livello che
costituisce il sistema.
Una possibile classificazione è quella che raggruppa le vulnerabilità principalmente in
3 categorie, che rappresentano tre diversi livelli di analisi
Vulnerabilità di Rete: si intende tutta l’infrastruttura di comunicazione di un sistema
informativo
Vulnerabilità dei Sistemi: si intende tutto il software che controlla un apparato
hardware dotato di processore e memoria
Vulnerabilità delle Applicazioni: si intende tutto il software, compilato od
interpretato che è funzionante su di un sistema

13. CICLO DI VITA
DELLA
VULNERABILITÀ
Le vulnerabilità hanno un proprio ciclo di vita scandito da varie fasi:
 Creazione: la vulnerabilità nasce nel momento in cui viene scritto il codice e tale
codice viene rilasciato. Tuttavia in questa prima fase, la vulnerabilità pur esistendo
non è nota, quindi non rappresenta un problema.
 Scoperta: La vulnerabilità viene scoperta, ma è nota solo a un gruppo ristretto di
individui. Tuttavia questi cominciano a sfruttarla per attaccare i vari sistemi
vulnerabili.
 Condivisione/Annuncio: Viene diffusa la conoscenza della vulnerabilità. In questa
fase spesso vengono anche creati automatismi per sfruttare la vulnerabilità, non è
quindi necessario essere degli esperti di hacking. In questa fase gli attacchi
crescono a dismisura.
 Pubblicazione della patch: Viene creata la patch, ossia una correzione al codice
che mira a risolvere la vulnerabilità.. E’ interessante notare, che in questa fase, gli
attacchi continuano ad aumentare, per iniziare a scendere molto dopo che la
patch sia stata distribuita.
 Installazione della patch: In questa fasi si procede all'installazione della patch e
alla risoluzione della vulnerabilità. Gli attacchi qui si annullano del tutto.

14. CICLO DI VITA
DELLA
VULNERABILITÀ

15. DATABASE
VULNERABILITÀ
Le vulnerabilità sono raccolte e descritte in DB. Un DB di vulnerabilità è una
piattaforma volta a raccogliere, mantenere e diffondere informazioni circa la scoperta
di nuove vulnerabilità.
Una delle voci presenti in molti database risulta essere quella dedicata allo Scoring.
Il CVSS (metodo di scoring) determina lo score da assegnare ad una vulnerabilità
basandosi su 3 tipi di metriche:
 Base: rappresenta le caratteristiche di una vulnerabilità che sono costanti nel
tempo ed indipendenti dal contesto in cui si trovano. Confidenzialità, integrità e
disponibilità
 Temporal: rappresenta le caratteristiche di una vulnerabilità che cambiano nel
tempo. Exploit
 Environmental: rappresenta le caratteristiche di una vulnerabilità che sono
rilevanti rispetto al contesto utente in cui vengono considerate. Impatti Collaterali.
Dalla combinazione di queste 3 metriche si ottiene poi lo score definitivo, un valore
compreso tra 0 e 10, associato alla vulnerabilità

16. COMMON
VULNERABILITIES
AND EXPOSURES
 Nei decenni passati la maggior parte dei tools di sicurezza
informatica usavano propri database i propri nomi per
identificare le vulnerabilità di un sistema
 Il Common Vulnerabilities and Exposures, o CVE è un
dizionario pubblico di vulnerabilità e falle di sicurezza note
 Il CVE è progettato per raccogliere e standardizzare la
classificazione delle vulnerabilità a livello mondiale
 Il processo per la creazione di un nuovo CVE comincia con la
scoperta di una vulnerabilità a cui viene assegnato un
identificatore CVE da un authority CNA una volta che questi
è stato verificato

17. ESEMPIO CVE

18. VANTAGGI CVE
 All'interno del catalogo CVE non troviamo informazioni circa i rischi,
l'impatto, soluzioni, proposte, informazioni tecniche dettagliate o indici
di sicurezza. Queste informazioni sono già presenti già nei database di
vulnerabilità e il CVE non vuole replicarle
 Il CVE ha invece il compito di fornire uno standard in modo da facilitare
la comunicazione tra i diversi database
 La semplice conoscenza dell'identificatore comune consente di accedere
velocemente e accuratamente alle informazioni sulla vulnerabilità,
attraverso sorgenti di informazioni multiple che sono tutte compatibili
con CVE
 Gli identificatori CVE inoltre forniscono una base di riferimento per la
valutazione della copertura degli strumenti e dei servizi così che gli
utenti possono determinare quale tool è il più efficace e appropriato in
base alle proprie esigenze

19. METODOLOGIE
OWASP

20. CENNI STORICI
 Nel 2001, nasce negli Stati Uniti il progetto OWASP (Open
Web Application Security) con lo scopo di promuovere e
diffondere le problematiche legate alla sicurezza informatica.
 OWASP è Open Source
 OWASP ha redatto grazie alla collaborazioni di moltissimi
professionisti del settore, delle linee guida per lo sviluppo
sicuro degli applicativi web.
 OWASP redige la Top 10 delle problematiche di sicurezza.
 OWASP redige Guide utili allo sviluppo, test e
implementazione del maturity model
 OWASP ha inoltre in attivo decine di altri progetti dedicati
alla web security

21. LINEE GUIDA
Owasp propone delle linee guida per lo sviluppo e
progettazione di applicazioni web sicure.
 Minimizzare l'area della "superficie di attacco"
 Principio del Secure by default
 Principio del Least Privilege
 Principio del Defense in depth
 Terminare in modo "sicuro"
 Considerare i sistemi esterni come insicuri
 Principio della Separation of Duties
 Non fidarsi del «Security Through Obscurity»

22. GUIDE -
DEVELOPER
Al fine di comprendere ed eliminare le cause della software
non sicuro, OWASP ha sviluppato la guida per lo sviluppo
delle applicazioni web sicure pensata per:
 Sviluppatori per implementare i meccanismi di sicurezza
ed evitare le vulnerabilità;
 Project Manager che la utilizzano per identificare le
attività da svolgere (threat modeling, code review,
development);
 Team di Sicurezza che la usano per apprendere le
tematiche di application security e l’approccio per la
messa in sicurezza;

23. GUIDE - CODE
REVIEW
Descrive la metodologia OWASP per revisionare il codice di un’applicazione (white box
testing). Reviewing Code usata per:
 Buffer Overruns and Overflows
 OS Injection
 SQL Injection
 Data Validation
 XSS issues
 Cross-Site Request Forgery issues
 Error Handling
 Logging Issues
 Secure Code Environment
 Authorization Issues
 Authentication
 Session Integrity issues
 …

24. GUIDE - TEST
Descrive la metodologia OWASP per testare un applicativo
web (white, gray & black box testing)
Approccio della metodologia:
 Definita
 Consistente
 Ripetibile
 Di qualità

25. PROGETTI -
ASVS
 Il progetto OWASP Application Security Verification Standard (ASVS) fornisce una base
per la verifica e il controllo tecnico dedicato alla protezione delle applicazioni web.
Fornisce inoltre agli sviluppatori un elenco di requisiti per lo sviluppo sicuro.
 L'obiettivo di ASVS è di fornire uno standard aperto per eseguire la verifica della
protezione delle applicazioni Web.
 Questo standard può essere utilizzato per stabilire un livello di fiducia nella sicurezza delle
applicazioni Web.
 I requisiti sono stati sviluppati tenendo presenti i seguenti obiettivi:
 Utilizzo come metrica - Fornire agli sviluppatori di applicazioni e ai proprietari delle
applicazioni un punteggio per valutare il grado di fiducia che può essere inserito
nelle applicazioni Web
 Utilizzo come guida – dare agli sviluppatori una linee guida sotto forma di checklist
da seguire per rinforzare la security nei sorgenti
 Uso durante progetti o software selection- Fornire una base per le specifiche di
sicurezza implementate o richieste durante lo sviluppo di software o la software
selection

26. PROGETTI -
MATURITY
MODEL
Software Assurance Maturity Model (SAMM) è un Framework aperto che aiuta le
aziende a formulare ed implementare una strategia per la software security
adattandola ai rischi specifici che devono essere affrontati.
Le risorse fornite dal Framework aiuteranno a:
 Valutare le pratiche di sicurezza esistenti di un'organizzazione
 Costruire un programma di sicurezza equilibrato dedicato alla software security
reiterabile
 Dimostrare i miglioramenti concreti del programma applicato attraverso un
meccanismo di scoring
 Definire e misurare le attività legate alla sicurezza in un'organizzazione

27. OWASP TOP
10 -
INJECTION

28. OWASP TOP 10
 Il progetto OWASP Top Ten è una classifica delle 10 vulnerabilità più
comuni e più pericolose a cui possono essere soggette al giorno d'oggi
le applicazioni web.
 La guida si focalizza sull'identificare i rischi più gravi per una vasta
gamma di organizzazioni.
 Per ognuno di questi rischi vengono fornite informazioni utilizzando
degli schemi di valutazione che tengono conto di:
 Vettore di attacco
 Diffusione
 Individuazione e Impatto Tecnico.
Gli agenti di minaccia dipendono dalle specifiche applicazioni, pertanto ogni
azienda dovrebbe valutare personalmente il rischio focalizzandosi sugli
aspetti caratteristici della propria impresa.

29. RISK IS A PATH
RISK is a path from Threat Agent to Business Impact

30. RISK FACTOR
SUMMARY

31. A1- INJECTION
Le Injection Flaws, si verificano quando dati non validati sono inviati come parte di un
comando o di una query al loro interprete. Il dato infetto può quindi ingannare tale
interprete, eseguendo comandi non previsti o accedendo a dati per i quali non si ha
l'autorizzazione.
 Sfruttabilità Facile. L'attaccante invia del semplice testo che sfrutta la sintassi
dell'interprete. Ogni sorgente di dati può essere un vettore di Injection, comprese
le sorgenti interne.
 Diffusione: Comune - Individuazione: Medio. Un'injection si verifica quando
un'applicazione invia dei dati non fidati ad un interprete. Tali debolezze sono
spesso presenti nel codice legacy, principalmente nelle query SQL, LDAP, nei
comandi OS, negli Header SMTP, nei parametri dei programmi ecc. E' più facile
individuare un'injection tramite analisi del codice che tramite testing.
 Impatto: Severo. Un' Injection può comportare perdita o corruzione di dati,
mancanza di tracciabilità, negazione d'accesso e, in alcuni casi il controllo
completo dell'host.

32. DEMO -
AGENDA
 INTRODUZIONE
 FINGERPRINTING
 Ispezione Header HTTP
 Utilizzo di un Directory Buster
 RILEVAMENTO ED EXPLOITATION DI SQL INJECTION
 Rilevamento di SQL Injection
 Introduzione a SQL
 Rilevamento basato su Integer
 Rilevamento basato su String
 Exploit di SQL Injection
 Utilizzo della Keyword UNION
 Exploit di SQL Injection con UNION
 Estrazione Informazioni
 ACCESSO AMMINISTRATIVO ED ESECUZIONE DI CODICE
 Cracking delle password
 Upload di WebShell ed esecuzione di codice
 CONCLUSIONI

33. DEMO

34. CONCLUSIONI
Utilizzare Injection per aprire una porta
dopo essere stati dal dentista 

35. CONCLUSIONI
Evitare pedaggi e multe 

36. CONCLUSIONI
Ingannare le telecamere di sorveglianza
riguardo la nostra identità 

38. GRAZIE!