UNIVERSITÀ DI PERUGIA
DIPARTIMENTO DI MATEMATICA E INFORMATICA
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Metodologie di Secure
Programming
Prof. Stefano Bistarelli
Università “G. d’Annunzio”
Dipartimento di Scienze, Pescara
C
Consiglio Nazionale delle
Ricerche
Iit
Istituto di Informatica e Telematica - Pisa
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Secure programming ~ defensive programming



Design delle applicazioni inteso a garantirne il funzionamento a
dispetto di un uso scorretto delle stesse.
Idea simile alla progettazione di oggetti che ne garantiscono l’uso
corretto
 fornelli che lasciano passare gas solo se e’ accesa la fiamma
 Prese e spine con versi obbligati
Obbiettivo generico di migliorare il codice delle applicazioni:
 Qualità (riducendo i bugs)
 Rendendolo più comprensivile per la fase di audit (alpha-beta
testing)
 Renderlo corretto (fa ciò che deve) e completo (fa solo quello!)
S. Bistarelli - Metodologie di Secure
Programming
2
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Nothing is assumed!

In programmazione difensiva nulla si assume.

TUTTI gli errori devono essere appositamente gestiti: non così 

Ancor peggio se errore ma non genero eccezione 

Se introduco piu’ di 256 caratteri come input?


E perché mai uno dovrebbe inserire una stringa cosi’ lunga?
Defensive programming  questo bug non deve esistere!

questo bug dimostra quello che vedremo essere il temibile buffer
overflow exploits
S. Bistarelli - Metodologie di Secure
Programming
3
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Tecniche di programmazione difensiva 1

Ridurre la complessità del codice



Revisione del codice sorgente





Minore possibilità di bugs (e di security problems)
… obfuscation technologies?   (forse la vedremo)
Free software
Code audit esterno
Self code audit
Fase di test
Source code reuse

Attenzione!!!
S. Bistarelli - Metodologie di Secure
Programming
4
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Tecniche di programmazione difensiva 2

Input/ouput validation



Code injection!!! 
Canonicalization 
Tutto il codice è pericoloso

least privilege principle



Mai sa o root
Mai piu’ permessi dei necessari
Tutti i dati sono importanti

E pericolosi (tainted variables!)
S. Bistarelli - Metodologie di Secure
Programming
5
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Il nostro corso …

Prerequisiti

intuire la logica di un programma scritto in C, C#,
ASP, PHP 



Non è richiesto saper programmare in C, C#, ASP, PHP

Conoscenza interfacce windows e conoscenza di
base del sistema unix (linux)
Corso difficile …

Spero renderlo piu’ semplice possibile …
S. Bistarelli - Metodologie di Secure
Programming
6
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Code injection

Un film … in inglese!! 


TheCodeRoom
E una discussione …
S. Bistarelli - Metodologie di Secure
Programming
7
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Errori del codice

Un errore del codice può influire sulla sicurezza del software
(in alcuni casi con conseguenze catastrofiche).

Ad esempio nel giugno 1996 il satellite europeo Ariane 5 è
esploso subito dopo il lancio a causa di un errore nel
software; il programma tentò di inserire un numero di 64 bit in
uno spazio di 16 bit, provocando un overflow.
S. Bistarelli - Metodologie di Secure
Programming
8
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Errori del codice: altri esempi

Nel 1998 un bug negli switch Cisco provocò il blocco della rete
frame relay Interspan di AT&T che collegava 6.600 clienti.

Nel 1999 il servizio di eBay fu sospeso per 22 ore a causa di
errori nel software fornito da Sun Microsystems.

Nel 1999 in uno degli script CGI di Hotmail fu scoperto un bug
che permetteva di accedere agli account di posta elettronica di
altri utenti.

Nel 2004 la Microsoft rilascia il Service Pack 2 per Windows XP,
dopo pochi giorni vengono scoperti 2 nuovi security bug, uno su
Internet Explorer (ver. > 5) ed uno su Outlook Express.
S. Bistarelli - Metodologie di Secure
Programming
9
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Errori del codice

I difetti di implementazione sono molto più frequenti, e più seri, di
quelli di progettazione.

Un software sicuro deve essere in grado di funzionare anche in
presenza di errori subdoli, appositamente introdotti da un
aggressore intelligente e con la chiara intenzione di
compromettere la sicurezza del sistema.

Il metodo normalmente utilizzato per trovare gli errori casuali è il
test della versione beta.

Il tempo dedicato a questo test viene sempre più ristretto per
esigenze commerciali. Ultimamente la tendenza è quella di far
fare il beta testing agli utenti!

S. Bistarelli - Metodologie di Secure
Programming
10
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione

Attacchi basati sugli errori del
codice
La maggior parte dei problemi di sicurezza dei computer sono
una conseguenza della presenza di errori nel software (si pensi
ad esempio ai virus).

Sfruttando questi bug è possibile, a volte, prendere il controllo
del sistema (ad esempio in ambiente Unix eseguire comandi da
root).

I bug di sicurezza sono molto più difficili da scovare rispetto ai
normali bug di funzionamento poichè i primi non si manifestano
apertamente, vengono scoperti solo quando qualcuno trova il
modo di sfruttarli.

Questo è il motivo per cui ottenere un sistema sicuro è molto più
difficile che ottenere un sistema privo di bug di funzionamento.
S. Bistarelli - Metodologie di Secure
Programming
11
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Attacchi basati sugli errori del
codice

I bug di sicurezza non sono rilevati normalmente attraverso la
procedura di beta testing.

Il test di sicurezza di un software richiede molto tempo e deve
essere affidato ad un esperto che conosca bene l'argomento
(anche se non è detto che ciò sia sufficiente...).

Una volta scoperti, i problemi di sicurezza vengono sfruttati
finchè qualcuno non trova il modo di risolverli (attraverso il
rilascio di patch o service pack).

Il lasso di tempo che intercorre tra la pubblicazione di un
security bug ed il rilascio della patch è di vitale importanza per la
sicurezza di un sistema.
S. Bistarelli - Metodologie di Secure
Programming
12
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Attacchi basati sugli errori del
codice

Ultimamente si è parlato molto di full disclosure ossia della libertà
di diffondere liberamente qualsiasi informazione sulla sicurezza
di un sistema informatico.

Chi scopre un security bug ha il dovere di informare gli autori del
sistema per dare loro il tempo di rilasciare le patch o ha il diritto
di diffondere pubblicamente la notizia senza nessun
avvertimento?

Ultimamente la tendenza è quella di pubblicare la notizia del
security bug senza troppe specifiche tecniche ed avvisare
contemporaneamente l'autore del sistema incriminato. Una volta
rilasciate le patch vengono divulgati i dettagli tecnici (ovviamente
non tutti seguono queste indicazioni).
S. Bistarelli - Metodologie di Secure
Programming
13
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Canali di diffusione dei security bug

Dove vengono diffuse le notizie sui security bug?

Esistono diversi enti internazionali che si occupano di sicurezza
informatica, il più famoso è il CERT Coordination Center www.cert.org
che gestisce un archivio di tutti gli advisories sullo sicurezza nella
sezione http://www.cert.org/nav/index_red.html

Altre organizzazioni sono il NIST Computer Security
Division,http://csrc.nist.gov/, che gestisce un database on-line di
vulnerabilità, l'IACT Metabase, il FIRST un forum sui problemi legati alla
sicurezza,http://www.first.org/, etc.

Esistono anche moltissime mailing-list, tra le più famose: bugtraq, full
disclosure, sikurezza.org (italiana).

In Italia esiste il CLUSIT, Associazione Italiana per la sicurezza
informatica http://www.clusit.it fondata dal Dipartimento di Informatica e
Comunicazione dell'Università degli Studi di Milano.
S. Bistarelli - Metodologie di Secure
Programming
14
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Attacchi basati sugli errori del
codice

Occorre sottolineare che i bug del software (e quindi i problemi di
sicurezza) sono inevitabili.

Ogni qual volta un esperto sufficientemente dotato decide di
analizzare un programma di protezione, finisce inevitabilmente
per trovare qualche errore casuale in grado di compromettere la
sicurezza del sistema.

Più il software è complesso maggiore è il numero di problemi
riscontrati.

Ad esempio Windows XP contiene circa 40 milioni di linee di
codice, Debian Gnu/Linux 2.2 circa 55 milioni (fonte:
http://www.dwheeler.com/sloc/).
S. Bistarelli - Metodologie di Secure
Programming
15
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Onnipresenza degli errori

Secondo le stime di Carnegie Mellon University, sono presenti
mediamente dai 5 ai 15 bug ogni mille righe di codice. Molti di
questi sono piccoli errori e, poichè non influenzano le prestazioni,
non vengono mai notati. Tuttavia, ognuno di questi bug potrebbe,
in teoria, compromettere la sicurezza del sistema.

Ad esempio su 55 milioni di linee di codice (Gnu/Linux) queste
stime indicano la presenza di un numero di bug variabile da
275'000 a 825'000!

L'unico modo per migliorare la sicurezza di un sistema è il
continuo aggiornamento. Secondo alcune stime, il 99% di tutti gli
attacchi sferrati attraverso Internet sarebbero stati evitati se gli
amministratori avessero usato le versioni più aggiornate del
software installato nei loro sistemi. (fonte: Bruce Schneier)
S. Bistarelli - Metodologie di Secure
Programming
16
UNIVERSITÀ DI PERUGIA
DIPARTIMENTO DI MATEMATICA E INFORMATICA
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Progetto OWASP
le 10 vulnerabilità più critiche delle
applicazioni Web
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Web Application Security e OWASP Top 10
Il progetto OWASP
http://www.owasp.org/
Le dieci vulnerabiltà più comuni: OWASP Top10

Meccanismi di autenticazione non adeguati

Crash del servizio: Buffer overflow

Furto di credenziali di autenticazioni: Cross Site
Scripting

Manipolazione dei dati aziendali: SQL Injection

Furto di identità: Errata gestione delle sessioni
S. Bistarelli - Metodologie di Secure
Programming
18
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Web Application Security
// Trend

Sempre più aziende sono on-line

Sempre più utenti sono on-line: everyone, everywhere, everytime
// Conseguenze
•
New Business
•
New security risk: confidential data, thief of identity
// Quali problemi?
•
Why good people write bad code -Graff e van Wyk in “Writing secure code”
•
No sviluppo “sicuro” degli applicativi web
•
Firewall and SSL non sono soluzioni di sicurezza completi
Fonte: http://www.internetworldstats.com/stats.htm
S. Bistarelli - Metodologie di Secure
Programming
19
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Misure tradizionali e incidenti di sicurezza

Gli Incidenti di sicurezza coinvolgono aziende che utilizzano:

Firewall: dal momento in cui sia consentito il protocollo HTTP in ingresso sul web server, un
attaccante puo’ inserire qualsiasi informazione nelle richieste

IDS:

sono facilmente bypassati a livello HTTP

non bloccano un attacco ma lo segnalano solamente

non possono fare nulla contro una richiesta cifrata

non sono in grado di rilevare nuovi attacchi

VPN: realizzano reti virtuali tra ambienti eterogenei garantendo riservatezza e
autenticazione tra i due peer.

AV: analizzano file ed e-mail per vedere se sono stati colpiti da nuovi virus; non sono
rilevanti per quanto riguarda l’HTTP

75% incidenti avviene via HTTP www.incidents.org

Encryption transport layer (SSL) + FW non risolvono il problema di
sviluppare un applicativo web “sicuro”
S. Bistarelli - Metodologie di Secure
Programming
20
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
HTTP
request
(cleartext
or SSL)
Concetti di WebAppSec
Accept from ANY to IP W.S. via
HTTP/HTTPS
Allow SQL
SQL
Database
Richiesta
Risposta
Web server
HTTP reply
(HTML,
Javascript,
VBscript,
etc)
Transport layer
HTTP/HTTPS over TCP/IP
•Apache
•IIS
•Netscape
etc…
App. server
Plugins:
•Perl
•C/C++
•JSP, etc
DataBase
Database
connection:
•ADO,
•ODBC, etc.
Canale e protocollo di comunicazione: HTTP layer 7 ISO/OSI, SSL layer 4-5
Server: Sviluppo applicativi web “sicuri”
S. Bistarelli - Metodologie di Secure
Programming
21
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Principali progetti OWASP


Linee guida:

Guida per la progettazione di applicativi web “sicuri”

OWASP Top Ten Vulnerability

Checklist per Web Application Vulnerability Assessment
Tool per Pentester e code reviewer:


WebScarab
WebGoat
S. Bistarelli - Metodologie di Secure
Programming
22
Master di I° livello in Sistemi e Tecnologie per la sicurezza dell'Informazione e della Comunicazione
Top Ten vulnerability list



OWASP mantiene una lista delle 10 vulnerabilità più critiche
di un applicativo web.
A1. Unvalidated Input
Aggiornate annualmente.
A2. Broken Access Control
A3. Broken Authentication
Sempre più accettata come standard: and Session Management








Federal Trade Commission (US Gov)
Oracle
Foundstone Inc.
@ Stake
VISA, MasterCard, American Express
Tradotta in italiano:
http://www.owasp.org/local/italy.html
http://www.clusit.it/whitepapers.htm
A4. Cross Site Scripting
(XSS) Flaws
A5. Buffer Overflow
A6. Injection Flaws
A7. Improper Error Handling
A8. Insecure Storage
A9. Denial of Service
A10. Insecure Configuration
Management
S. Bistarelli - Metodologie di Secure
Programming
23