ANALISI E GESTIONE DELLA SICUREZZA DI UNA COMPLESSA APPLICAZIONE WEB SECONDO LE LINEE GUIDA INTERNAZIONALI OWASP 2.0.

Transcript

1 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: chiar.mo Prof. A. F. Dragoni LAUREANDO: Vocino Angelo Anno Accademico 2006/2007

2 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

3 INDICE INDICE... 1 ELENCO DELLE FIGURE... 3 CAPITOLO I - Introduzione Obiettivo del lavoro Struttura della tesi CAPITOLO II - Talete: Autenticazione ed Autorizzazione Introduzione alle tecnologie usate in Talete: il framework.net Le applicazioni Asp.NET Il linguaggio C# La tecnologia AJAX Le implicazioni di sicurezza di AJAX Talete: come si presenta Progettazione della piattaforma Talete Analisi dei requisiti Diagrammi UML Diagramma dei casi d uso Diagramma delle attività Diagramma delle classi Implementazione della soluzione Collaudo del sistema CAPITOLO III - Progettare un applicazione: i design pattern Introduzione alla progettazione di applicazioni object-oriented Il significato dei design pattern Il cluster dei pattern GoF I design pattern usati in Talete CAPITOLO IV - La sicurezza nelle web applications Introduzione Evoluzione degli attacchi Caratteristiche e problematiche legate alla sicurezza La sicurezza dei dati Certificati Come lavora SSL Obiettivi SSL Come usare male SSL Principi di sicurezza in Asp.NET Autenticazione e autorizzazione in Asp.NET L utente in Asp.NET: Principal e Identity Web.config: il tag <authorization> API per la sicurezza Controlli per gestire l accesso e l autenticazione in Asp.NET La sicurezza in Asp.NET: il ViewState Il ViewState in Asp.NET

4 CAPITOLO V - La sicurezza nell architettura di un applicazione Architettura a più livelli di un applicazione web L SDL Il threat modeling Microsoft Threat Analysis & Modeling Tool Considerazioni sul threat modeling CAPITOLO VI - Gli attacchi e il progetto OWASP Progetto OWASP Unvalidated input SQL Injection Quanti danni può fare? Quale linguaggio e quale tecnologia? Proteggersi dalla SQL injection I vantaggi nascosti Tentativi di SQL Injection in Talete Broken Access Control Broken Authentication e Session Management Cross Site Scripting Buffer Overflow Injection Flaw Improper Error Handling Insecure Storage Denial of Service Insecure Configuration Management CAPITOLO VII - Test per valutare la sicurezza di Talete Gli strumenti per la sicurezza delle web applications Analisi del codice sorgente Black-box scanner Altri strumenti Web Vulnerability Scanner Conclusioni e sviluppi futuri

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

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

7 CAPITOLO I - Introduzione 5

8 CAPITOLO I - Introduzione 1.1 Obiettivo del lavoro 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

9 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 ( è 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

10 CAPITOLO I - Introduzione Figura 1 Home page di Talete 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

11 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 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

12 CAPITOLO I - Introduzione 1.2 Struttura della tesi 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

13 CAPITOLO II - Talete: Autenticazione ed Autorizzazione 11

14 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

15 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). Figura 3 Struttura del framework.net Le applicazioni Asp.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

16 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

17 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 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

18 CAPITOLO II - Talete: Autenticazione ed Autorizzazione consistente e ben definito gruppo di tipi di base 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

19 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

20 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

21 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

22 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 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

23 CAPITOLO II - Talete: Autenticazione ed Autorizzazione Ampliamento della superficie di attacco 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

24 CAPITOLO II - Talete: Autenticazione ed Autorizzazione 2.3 Talete: come si presenta 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: Figura 6 I 3 livelli di Talete Tra le aree abbiamo: 22

25 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

26 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

27 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à 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

28 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

29 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

30 CAPITOLO II - Talete: Autenticazione ed Autorizzazione Diagrammi UML 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 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

31 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

32 CAPITOLO II - Talete: Autenticazione ed Autorizzazione Figura 11 Diagramma dei casi d uso Diagramma delle attività 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

33 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

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

35 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

36 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

37 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

38 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

39 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 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

40 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

41 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

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

43 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

44 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

45 CAPITOLO III - Progettare un applicazione: i design pattern 3.2 Il significato dei 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

46 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

47 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

48 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

49 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: <connectionstrings> <add name="angelopc" connectionstring="data Source=localhost;Database=talete; User ID=root;Password=ciccio;" providername="mysql.data.mysqlclient"/> </connectionstrings> 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

50 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

51 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. <member name="m:telerik.webcontrols.radmenuitem.renderbegintag (System.Web.UI.HtmlTextWriter)"> <exclude/> <excludetoc/> </member> <member name="m:telerik.webcontrols.radsplitbar.rendercollapsebars (System.Web.UI.HtmlTextWriter)"> <exclude/> <excludetoc/> </member> 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

52 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<T>. Questa classe è la rappresentazione di un insieme di elementi di tipo T, che funge da wrapper per il tipo generico System.Collections.Generic.List<T>, 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 <T> con System.Collections.Generic.List<Organizzazione>: 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

53 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

54 CAPITOLO IV - La sicurezza nelle web applications 52

55 CAPITOLO IV - La sicurezza nelle web applications 4.1 Introduzione 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 Q,2007 Vulnerabilities 1,090 2,437 4,129 3,784 3,780 5,990 8,064 2,176 (da Figura 21 Statistiche degli attacchi nel

56 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

57 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

58 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

59 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 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

60 CAPITOLO IV - La sicurezza nelle web applications Sicurezza nell accesso ai dati 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

61 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

62 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 ( GeoTrust ( GlobalSign ( Thawte ( 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

63 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

64 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

65 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 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

66 CAPITOLO IV - La sicurezza nelle web applications Fase 2: Server_Hello 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

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

68 CAPITOLO IV - La sicurezza nelle web applications Obiettivi SSL 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 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 il dns non restituisce l indirizzo della banca, bensì quello del sito dell hacker che ha una pagina identica a 66

69 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

70 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

71 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 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

72 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

73 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 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

74 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

75 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

76 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

77 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: if (Page.User.IsInRole("Amministratore"))... con public IPrincipal User { get; } Web.config: il tag <authorization> Per controllare chi può accedere al sito web, c è bisogno di aggiungere regole di controllo dell accesso alla sezione <authorization> del file web.config. Questo è un esempio che duplica il comportamento di default: 75

78 CAPITOLO IV - La sicurezza nelle web applications Figura 32 Esempio n 1 di <authorization> 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 <authorization> 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

79 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 <authorization> 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

80 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: <allow users= Angelo /> <deny users= Angelo /> Con la figura seguente è possibile riassumere i concetti di autenticazione e autorizzazione in Asp.NET: Figura 35 Autenticazione e autorizzazione in Asp.NET API per la sicurezza 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

81 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 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

82 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

83 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

84 CAPITOLO IV - La sicurezza nelle web applications 2. SQLRoleProvider 3. WindowsTokenRoleProvider 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

85 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

86 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

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