Sicurezza in ASP.NET

Transcript

1 Capitolo 17 Sicurezza in ASP.NET In questo capitolo: Da dove provengono le minacce Il contesto di sicurezza ASP.NET Utilizzo dell autenticazione Forms L API di membership e di gestione dei ruoli Controlli inerenti alla sicurezza Conclusioni Molti sviluppatori hanno appreso da sé che la sicurezza non è una caratteristica che può essere aggiunta alle applicazioni esistenti o essere introdotta in seguito durante lo sviluppo. La sicurezza è intrinsecamente collegata alle funzioni di un applicazione e va pianificata fra le prime caratteristiche, durante la fase iniziale di progettazione. Per loro natura, le applicazioni Web sono soggette a diversi tipi di attacchi, il cui danno e impatto può variare abbastanza, in base alle caratteristiche dell applicazione stessa. L applicazione Web più sicura è l applicazione che effettivamente resiste agli attacchi, e non l applicazione che è solo progettata per resistere. La sicurezza è un puzzle piuttosto complesso la cui soluzione varia da un applicazione all altra. La cosa importante da ricordare è che, quasi sempre, la sicurezza si manifesta attraverso una miscela proficua di misure a livello di applicazione e a livello di sistema. ASP.NET semplifica la programmazione di applicazioni sicure fornendo una infrastruttura nativa che fornisce una protezione a livello di applicazione contro l accesso non autorizzato alle pagine Web. Si sappia, tuttavia, che questo tipo di sicurezza è solo una faccia della medaglia. Un sito Web realmente sicuro è particolarmente ben protetto contro gli attacchi server che possono essere utilizzati per scalare furtivamente le più alte mura protettive della logica dell applicazione. In questo capitolo, discuteremo il contesto di sicurezza di ASP.NET, compresa la relazione con i meccanismi di autenticazione lato server di Internet Information Services (IIS) e le pratiche di codifica ottimale per difendersi dagli attacchi Web. 805

2 806 Parte III Infrastruttura ASP.NET Da dove provengono le minacce Il concetto di sicurezza implica la presenza del nemico da cui proteggersi. Nella Tabella 17-1, sono riassunti i tipi più comuni di attacchi Web. Tabella I più comuni attacchi Web Attacco Scripting cross-site (XSS) Denial of Service (DoS) Eavesdropping Manomissione di campi hidden One-click Dirottamento di sessione Iniezione SQL Descrizione L input di un utente non sicuro viene propagato sulla pagina. L aggressore inonda la rete con richieste fittizie, sovraccaricando il sistema e bloccando il traffico regolare. L aggressore utilizza uno sniffer per leggere i pacchetti di rete non crittografati mentre vengono trasportati sulla rete. L aggressore manomette i campi nascosti non verificati (e sicuri) che contengono dati sensibili. Subdoli post HTTP vengono inviati via script. L aggressore ricava o sottrae un ID di sessione valido e si connette alla sessione di un altro utente. L aggressore inserisce un input subdolo che il codice concatena tranquillamente per formare pericolosi comandi SQL. La conclusione è che ogni qualvolta si inserisce qualsiasi tipo di input utente nel markup del browser ci si espone potenzialmente a un attacco di iniezione di codice (cioè, qualsiasi variazione di iniezione SQL e XSS). Inoltre, i dati sensibili non dovrebbero mai essere inviati sulla connessione (tantomeno come testo in chiaro) e devono essere memorizzati in modo sicuro sul server. Se esiste un modo per scrivere una applicazione a prova di proiettile e resistente alle manomissioni, può trattarsi solo della combinazione dei seguente aspetti: Norme di codifica: validazione dei dati, verifica del tipo e della lunghezza del buffer, e misure anti-manomissione Strategie di accesso ai dati: utilizzo di ruoli per assicurare che sul server sia utilizzato l account più debole possibile per limitare l accesso alle risorse sul server, e utilizzo di stored procedure o almeno di comandi con parametri Memorizzazione e amministrazione efficace: nessun invio di dati critici al client, utilizzo di valori hash per rilevare la manipolazione, autenticazione degli utenti e protezione delle identità, e applicazione rigorosa delle politiche per le password Come si può vedere da questo elenco, una applicazione sicura può essere prodotta solo dall impegno combinato degli sviluppatori, degli architetti e degli amministratori. Diversamente, non si immagini di poterla ottenere in maniera corretta.

3 Capitolo 17 Sicurezza in ASP.NET 807 Il contesto di sicurezza di ASP.NET Da un punto di vista dell applicazione, la sicurezza è per la maggior parte una questione di autenticazione degli utenti e di autorizzazione delle azioni sulle risorse di sistema. ASP.NET fornisce un ventaglio di meccanismi di autenticazione e autorizzazione implementati in combinazione con IIS, il.net Framework e i sottostanti servizi di sicurezza del sistema operativo. Il contesto di sicurezza complessivo di una applicazione ASP.NET si compone di tre livelli distinti: Il livello IIS associa un token di sicurezza valido al mittente della richiesta. Il token di sicurezza viene determinato in base al meccanismo corrente di autenticazione IIS. Il livello di processo worker ASP.NET determina l identità del thread del processo worker ASP.NET che serve la richiesta. Se abilitate, le impostazioni di impersonazione possono modificare il token di sicurezza associato al thread. L identità del modello di processo viene determinata dalle impostazioni nel file di configurazione o della metabase IIS, in base al modello di processo in uso. Il livello di pipeline ASP.NET ottiene le credenziali dell utente specifico che sta utilizzando l applicazione. Il modo in cui questo compito viene svolto dipende dalle impostazioni nei file di configurazione dell applicazione per ciò che concerne l autenticazione e l autorizzazione. Una impostazione comune per gran parte delle applicazioni ASP.NET è scegliere di utilizzare la Forms Authentication. Tra l altro, l identità del processo worker ASP.NET influenza l accesso ai file locali, alle cartelle e ai database. Chi esegue realmente la mia applicazione ASP.NET? Quando giunge una richiesta ASP.NET alla macchina Web server, IIS la prende in consegna e assegna la richiesta a uno dei thread in pool. IIS viene eseguito con l account SYSTEM, l account più potente in Windows. Da questo punto in poi, nell elaborazione di questa richiesta, vengono attraversati i tre contesti di sicurezza delle applicazioni ASP.NET che ho menzionato, uno dopo l altro. Il contesto di sicurezza del thread IIS Il thread che gestisce fisicamente la richiesta impersona una identità in base alle impostazioni correnti di autenticazione IIS: Basic, Digest, Integrated Windows o anonima. Se il sito è configurato per l accesso anonimo, l identità impersonata dal thread è quella che si imposta attraverso la finestra di dialogo mostrata nella Figura Per default, è denominata IUSR_xxx dove xxx è il nome della macchina. (La finestra di dialogo è la finestra di dialogo Properties dell applicazione IIS administrative manager.)

4 808 Parte III Infrastruttura ASP.NET Figura 17-1 Abilitazione dell accesso anonimo e modifica dei metodi di autenticazione del sito. L autenticazione Basic è uno standard HTTP virtualmente supportato da qualsiasi browser. Con questo tipo di autenticazione, una richiesta rimbalza indietro con un particolare codice di stato HTTP che il browser interpreta come richiesta di visualizzare una finestra di dialogo standard per richiedere le credenziali dell utente. Le informazioni raccolte vengono inviate a IIS, che tenta di confrontarle con gli account del Web server. Siccome le credenziali vengono inviate come testo codificato in Base64, essenzialmente come testo in chiaro, l autenticazione Basic è raccomandata solo per un utilizzo su canali sicuri HTTPS. L autenticazione Digest differisce in gran parte dall autenticazione Basic poiché esegue l hashing delle credenziali prima di inviarle. L autenticazione digest è una caratteristica HTTP 1.1 e, in quanto tale, non è supportata da alcuni vecchi browser. Inoltre, su Windows 2000 richiede che la password sia memorizzata sul server con crittografia reversibile. Ciò non è più un prerequisito con Windows Server Entrambi gli schemi di autenticazione Basic e Digest funzionano bene attraverso firewall e server proxy. L autenticazione Integrated Windows imposta una conversazione tra il browser e il Web server. Il browser passa le credenziali dell utente correntemente loggato, a cui non è richiesto di digitare nulla. L utente deve avere un account valido sul Web server o in un dominio trusted per poter essere autenticato. L autenticazione può avvenire per mezzo del metodo challenge/response NTLM o utilizzando Kerberos. La tecnica ha un supporto limitato del browser ed è irrealizzabile in presenza di firewall. Nota Esiste un ulteriore tipo di modalità di autenticazione e si basa sui certificati. Si possono utilizzare le caratteristiche di sicurezza Secure Sockets Layer (SSL) di IIS e utilizzare i certificati client per autenticare gli utenti che richiedono informazioni sul proprio sito Web. SSL verifica il contenuto del certificato inviato dal browser dell utente durante il login. Gli utenti ottengono i certificati client da una organizzazione indipendente sicura. In uno scenario intranet, gli utenti possono anche ottenere il proprio certificato da una authority gestita dall azienda stessa.

5 Capitolo 17 Sicurezza in ASP.NET 809 Dopo l autenticazione, il thread invia la richiesta al modulo esterno appropriato. Per una richiesta ASP.NET, ciò che accade dipende dal modello di processo utilizzato nell applicazione. Contesto di sicurezza del processo worker Nel modello di processo IIS 5.0, il thread IIS passa la richiesta a aspnet_isapi.dll che, a sua volta, avvia il processo worker aspnet_wp.exe. Nel modello di processo IIS 6.0, la richiesta viene accodata nel pool dell applicazione che ospita l applicazione ASP.NET e viene presa in consegna dalla copia del processo worker IIS w3wp.exe che serve il pool dell applicazione. Qual è l identità del processo worker? Se viene utilizzato il modello di processo IIS 5.0, il processo worker viene eseguito con le sembianze dell account ASPNET. ASPNET è un account locale che viene creato quando viene installato il.net Framework. Ha il minimo set di privilegi richiesti per il suo ruolo ed è di gran lunga meno potente dell account SYSTEM. Si può modificare l identità di un account esistente attraverso la seguente sezione del file machine.config: <processmodel username=... password=... /> Se viene utilizzato il modello di processo IIS 6.0, il processo worker ha l identità dell account NETWORK SERVICE. Si può modificarla attraverso la finestra di dialogo mostrata nella Figura Utilizzando IIS administrative manager, si seleziona il pool dell applicazione scelta e si clicca per vederne le proprietà. NETWORK SERVICE ha lo stesso insieme limitato di privilegi di ASPNET ed è un nuovo account predefinito in Windows Server 2003 e Windows XP. Figura 17-2 Impostazione dell identità di default del processo worker che serve un pool di applicazione in IIS 6.0.

6 810 Parte III Infrastruttura ASP.NET All interno del processo worker, un thread in pool prenderà in carico la richiesta per servirla. Qual è l identità di questo thread? Se nell applicazione ASP.NET l impersonazione è disabilitata, questo thread erediterà l identità del processo worker. Questo è ciò che accade per default. Se l impersonazione è abilitata, il thread worker erediterà il token di sicurezza passato da IIS. Si abilita l impersonazione nel file web.config come segue: <impersonation enabled= true /> C è molto altro da dire sulla impersonazione ASP.NET, in particolare sulla forma estesa di impersonazione in cui viene specificata una determinata identità. Discuteremo di ciò tra un attimo. Quando è attiva l impersonazione, l account del processo worker non cambia. Il processo worker continua a compilare le pagine e a leggere i file di configurazione utilizzando l account originale. L impersonazione viene utilizzata solo con il codice eseguito nella pagina e non per tutti i passi preliminari che si verificano prima che la richiesta sia passata all handler della pagina. Ad esempio, ciò significa che qualsiasi accesso ai file locali o a database si verifica utilizzando l account impersonato, non l account del processo worker. Contesto di sicurezza della pipeline ASP.NET Il terzo contesto di sicurezza indica l identità dell utente che effettua la richiesta. Lo scopo qui è autenticare l utente e autorizzare l accesso alla pagina e alle risorse che ingloba. Ovviamente, se la pagina richiesta è liberamente disponibile, non viene eseguito alcun ulteriore passo; l output della pagina viene generato e servito all utente. Per proteggere le pagine da accessi non autorizzati, una applicazione ASP.NET deve definire una politica di autenticazione: Windows, Passport o Forms. I moduli di autenticazione agganciano le richieste di pagine protette e si occupano di ottenere le credenziali dell utente. L utente viene diretto alla pagina solo se le credenziali sono ritenute valide e autorizzano all accesso alla risorsa richiesta. Modifica dell identità del processo ASP.NET In una situazione in cui si vuole modificare l account ASP.NET di default per attribuirgli più privilegi, come si dovrebbe procedere? È preferibile creare un account custom e utilizzarlo per il processo worker, o si dovrebbe optare perché il processo worker impersoni una determinata identità? Nota Difficilmente si può creare un nuovo account funzionale con meno privilegi di quelli concessi a ASPNET o NETWORK SERVICE. Se si fa un tentativo, bisogna effettuare una attenta fase di testing e assicurarsi che funzioni realmente con la propria applicazione.

7 Capitolo 17 Sicurezza in ASP.NET 811 Impostazione dell account di processo L utilizzo della sezione <processmodel> (per il modello di processo IIS 5.0) o l utilizzo della finestra di dialogo mostrata nella Figura 17-2 (per il modello di processo IIS 6.0) sono gli unici modi per modificare l identità reale del processo ASP.NET. Se si modifica l identità di processo, tutti i thread del processo utilizzeranno questa identità come identità base e non sarà necessario nessun lavoro extra in fase di commutazione di thread. Aspetto ancor più importante, è che si deve essere certi che il nuovo account abbia almeno i permessi completi sulla cartella Temporary ASP.NET Files. (Si riveda attentamente l elenco dei permessi concessi agli account standard ASP.NET, riportato nel paragrafo Privilegi dell account di default ASP.NET ). In alternativa, si può richiedere al processo worker di impersonare una determinata identità attraverso la sezione <identity> del file web.config. Si noti che se viene utilizzata una determinata impersonazione, ogni thread worker che elabora una richiesta deve impersonare l account specificato. L impersonazione deve essere eseguita per ciascuna commutazione di thread poiché un evento di commutazione di thread riporta l identità del thread all identità del processo. Impersonazione di una identità prestabilita Per impersonare una determinata identità, prima si definisce l account utente e poi si aggiunge una impostazione al file web.config. Il seguente frammento mostra un esempio: <identity impersonate= true username= MyAspNetAccnt password= ILoveA$p*SinceVer3.0 /> Come si è detto prima, l impersonazione non modifica realmente l identità fisica del processo che esegue ASP.NET. Più semplicemente, tutti i thread che danno servizio nel contesto del processo worker ASP.NET impersonano sempre un determinato utente per tutta la durata dell applicazione. L impersonazione di una determinata identità è differente dalla classica impersonazione per richiesta, come l impersonazione dell identità dell utente Windows che effettua la richiesta. La impersonazione per richiesta si riferisce alla situazione in cui si abilita l impersonazione senza specificare una determinata identità. In questo caso, il token di sicurezza con le informazioni sull identità viene creato da IIS e viene ereditato dal processo worker. Se viene coinvolta una identità prestabilita, il token di sicurezza deve essere generato dal processo worker ASP.NET. Tuttavia, se viene eseguito con un account poco privilegiato, talvolta il processo worker ASP.NET è privo del permesso per fare ciò. All interno della caratteristica di impersonazione prestabilita Un processo in esecuzione con un account non amministrativo non può impersonare un account specifico su Windows 2000 a meno che non gli siano concessi i privilegi appropriati. Con Windows 2000, un processo richiede il privilegio Agisce Come Parte del Sistema Operativo per impersonare una identità prestabilita. Si tratta effettivamente di un privilegio forte e potente che, per motivi di sicurezza, gli account di processi non amministrativi come ASPNET e NETWORK SERVICE generalmente non avranno.

8 812 Parte III Infrastruttura ASP.NET Questo prerequisito scompare con Windows XP e Windows Server 2003, il che rende possibile a processi privi del privilegio Agisce Come Parte del Sistema Operativo di impersonare una determinata identità. In ASP.NET 1.1, tuttavia, l impersonazione di una determinata identità è possibile anche su macchine dotate di Windows 2000 e di IIS 5.0. Il runtime ASP.NET 1.1 ricorre ad alcune tecniche per rivettorizzare l invocazione nuovamente al modulo aspnet_isapi.dll, che è in esecuzione all interno di IIS 5.0 e con l account SYSTEM. Sostanzialmente, l estensione ISAPI ASP.NET 1.1 crea il token di sicurezza e lo duplica nello spazio di memoria del processo worker. In questo modo, ASP.NET 1.1 supporta l impersonazione prestabilita senza richiedere il privilegio Agisce Come Parte del Sistema Operativo per l account del processo worker. In definitiva, ci si attenda di avere delle difficoltà con l impersonazione prestabilita solo se si stanno ancora eseguendo applicazioni ASP.NET 1.0 con Windows In tal caso, perché funzioni l impersonazione è necessario eseguire le proprie applicazioni ASP.NET con l account SYSTEM, con tutte le ripercussioni di sicurezza che ciò implica. Impersonazione attraverso l account anonimo Una terza possibilità di modificare l identità del processo worker ASP.NET è l impersonazione attraverso l account anonymous. L idea è che l applicazione ASP.NET conceda l accesso agli utenti anonimi, e che l account anonymous sia configurato per essere l account richiesto per l applicazione. In tal caso, l applicazione utilizza una impersonazione per richiesta e il codice ASP.NET viene eseguito con l account impersonato. L account del processo rimane impostato a ASPNET o NETWORK SERVICE, il che significa che non bisogna preoccuparsi della replicazione nel nuovo account dell insieme minimo di permessi sulle cartelle che consentono ad ASP.NET di lavorare. Privilegi dell account ASP.NET di default Di tutte le assegnazioni possibili di diritti utente, ad ASPNET e NETWORK SERVICE vengono concessi solo i seguenti cinque diritti: Accesso a questo computer dalla rete Negato il logon localmente Negato il logon attraverso Terminal Services Log on come job batch Log on come servizio Inoltre, agli account vengono attribuiti alcuni permessi NTFS per operare su certe cartelle e per creare file e assembly temporanei. Le cartelle coinvolte sono le seguenti: Cartella root del.net Framework Questa cartella contiene alcuni assembly di sistema del.net Framework a cui ASP.NET deve essere in grado di accedere. La

9 Capitolo 17 Sicurezza in ASP.NET 813 cartella fisica è normalmente Microsoft.NET\Framework\[versione] ed è posizionata nella cartella Windows. ASP.NET ha solo permessi di lettura e di esplorazione su questa cartella. File temporanei ASP.NET Questa cartella rappresenta il sottoalbero del filesystem in cui vengono generati tutti i file temporanei. Ad ASP.NET è concesso il controllo completo sull intero sottoalbero. Global Assembly Cache ASP.NET deve avere il permesso di lettura sugli assembly della Global Assembly Cache (GAC). La GAC si trova nella cartella Windows\ Assembly\GAC. La cartella GAC non è visibile con Windows Explorer, ma si possono visualizzare gli assembly installati aprendo la cartella Windows\Assembly. Cartella Windows System Il processo ASP.NET deve accedere e leggere la cartella Windows System32 per caricare ogni DLL Win32 necessaria. Cartella root dell applicazione Il processo ASP.NET deve accedere e leggere i file che costituiscono l applicazione Web. La cartella viene tipicamente posizionata in Inetpub\wwwroot. Root del sito Web ASP.NET può avere necessità di scandire la root del Web server (tipicamente Inetpub\wwwroot) alla ricerca di file di configurazione da leggere. Un applicazione ASP.NET in esecuzione con un account privo di alcuni di questi permessi potrebbe fallire. La concessione di almeno tutti questi permessi è altamente raccomandata per tutti gli account utilizzati per l impersonazione prestabilita dell account. Il livello di trust delle applicazioni ASP.NET Le applicazioni ASP.NET sono costituite da codice managed e vengono eseguite all interno del Common Language Runtime (CLR). Nel CLR, il codice in esecuzione viene assegnato a una zona di sicurezza in base alla evidence che fornisce sulla propria origine: ad esempio, l URL di provenienza. Ciascuna zona di sicurezza corrisponde a un set di permessi. Ciascun set di permessi corrisponde a un livello di trust. Per default, le applicazioni ASP.NET vengono eseguite nella zona MyComputer con full trust. Questa impostazione di default è semplicemente pericolosa? Un applicazione ASP.NET viene eseguita sul Web server e non nuoce all utente che si connette ad essa attraverso il browser. Un applicazione ASP.NET non può essere consumata in altri modi se non attraverso il browser. Pertanto perché parecchie persone avvertono brividi lungo la schiena quando pensano al livello full trust di ASP.NET? Il problema non è nell applicazione ASP.NET di per sé, ma è nel fatto che l applicazione è pubblicamente esposta su Internet: uno degli ambienti più ostili per la sicurezza dei computer che si possa immaginare. Se un account ASP.NET full trusted dovesse essere soggetta a un hijacking, un hacker potrebbe eseguire azioni limitate dall interno del thread worker. In altri termini, una applicazione full trusted pubblicamente esposta è una potenziale piattaforma per gli hacker per lanciare attacchi. Meno trusted è una applicazione, più sicura è.

10 814 Parte III Infrastruttura ASP.NET La sezione <trust> Per default, le applicazioni ASP.NET vengono eseguite senza limitazioni e gli è permesso fare tutto ciò che è permesso al relativo account. Le effettive restrizioni di sicurezza che talvolta si applicano alle applicazioni ASP.NET (ad esempio, l inabilità di scrivere file) non rappresentano un segno di trust parziale, ma più semplicemente l effetto dell account sottoprivilegiato con cui normalmente vengono eseguite le applicazioni ASP.NET. Alterando la sezione <trust> del file web.config root, si possono configurare i permessi di code access security di una applicazione Web e decidere se deve essere eseguita in modalità full trust o parzialmente trust. <trust level= Medium originurl= /> La Tabella 17-2 descrive i livelli di trust disponibili. Tabella Livelli permessi nella sezione <trust> Livello Full High Medium Low Minimal Descrizione Le applicazioni vengono eseguite in modalità full trust e possono eseguire codice nativo arbitrario nel contesto di processo in cui girano. È l impostazione di default. Il codice può utilizzare gran parte dei permessi che supportano il trust parziale. Ciò è appropriato per le applicazioni che si vogliono eseguire con i minimi privilegi per mitigare i rischi. Il codice può leggere e scrivere nelle proprie directory applicative e può interagire con i database. Il codice può leggere le proprie risorse applicative ma non può interagire con le risorse posizionate all esterno dello spazio dell applicazione. Il codice non può interagire con alcuna risorsa protetta. Appropriato per l hosting di siti non professionali che intendono semplicemente supportare del codice HTML generico e una logica business altamente isolata. Nota Le applicazioni Web e i Web service implementati utilizzando il.net Framework versione 1.0 vengono sempre eseguiti con permessi non limitati di accesso da codice. I livelli configurabili elencati nella Tabella 17-2 non si applicano alle applicazioni ASP.NET 1.0. In effetti, limitare l insieme di operazioni che una applicazione può eseguire può essere inizialmente traumatico. Tuttavia, sulla lunga distanza (leggasi, se non ci arrende e si procede con la consegna dell applicazione) produce codice migliore e più sicuro.

11 Capitolo 17 Sicurezza in ASP.NET 815 Nota La sezione <trust> supporta un attributo denominato originurl. L attributo è una sorta di termine improprio. Impostandolo, all URL specificata viene concesso il permesso di accedere a una risorsa HTTP utilizzando una classe Socket o WebRequest. La classe permesso coinvolta è WebPermission. Naturalmente, il permesso Web viene concesso solo se il livello <trust> specificato lo supporta. I livelli trust da Medium in su hanno questo supporto. Permessi ASP.NET Riesaminiamo in maggior dettaglio il permesso concesso alle applicazioni ASP.NET quando vengono applicati i vari livelli di trust. I principali permessi ASP.NET per ciascun livello di trust vengono riassunti in Tabella Tabella Principali permessi dei livelli di trust ASP.NET High Medium Low Minimal FileIO Non limitato Read/Write nello spazio dell applicazione Read Nessuno IsolatedStorage Non limitato ByUser ByUser (massimo di 1 MB) Nessuno Printing DefaultPrinting Come High Nessuno Nessuno Security Assertion, Execution, ControlThread, ControlPrincipal Come High Execution Execution SqlClient Non limitato Non limitato (nessuna password vuota permessa) Nessuno Nessuno Registry Non limitato Nessuno Nessuno Nessuno Environment Non limitato Nessuno Nessuno Nessuno Reflection ReflectionEmit Nessuno Nessuno Nessuno Socket Non limitato Nessuno Nessuno Nessuno Web Non limitato Connessione all host di origine, se configurato Come High Nessuno Ulteriori informazioni di dettaglio sui permessi effettivamente concessi ai livelli di trust di default sono disponibili nei file di configurazione della sicurezza di ciascun livello. Il

12 816 Parte III Infrastruttura ASP.NET nome del file di ciascun livello è memorizzato nella sezione <trustlevel>. In definitiva, le applicazioni full-trust vengono eseguite senza limitazioni. Le applicazioni high-trust hanno permessi di lettura/scrittura per tutti i file nel proprio spazio applicativo. Tuttavia, l accesso fisico ai file viene comunque regolato dalle access control list NTFS sulla risorsa. Le applicazioni high-trust hanno un accesso non limitato a Microsoft SQL Server ma non, ad esempio, alle classi OLE DB. (Il permesso OleDbPermission e altri permessi sui provider managed vengono negati a tutti tranne che alle applicazioni full trust). Le invocazioni alla reflection vengono negate ad eccezione di quelle dirette a classi del namespace System.Reflection.Emit. Le applicazioni Medium hanno un accesso non limitato a SQL Server, ma solo finché non utilizzano password vuote per gli account. WebPermission viene concesso sia ad applicazioni con livello medium sia low, ma richiede che l URL sia configurata nella sezione <trust> attraverso l attributo originurl. Le applicazioni low-trust hanno un permesso a sola lettura per i file delle proprie directory applicative. L isolated storage è ancora permesso ma è limitato a una quota di 1 MB. Un regola pratica è che il livello di trust Medium dovrebbe essere adeguato per gran parte delle applicazioni ASP.NET e la sua applicazione non dovrebbe causare significativi grattacapi, purché non si debba accedere a oggetti legacy COM o a database esposti via provider OLE DB. Concessione di privilegi al di là del livello di trust E se uno dei task da eseguire richiede privilegi che il livello di trust non concede? In tal caso, ci sono due approcci essenziali. L approccio più semplice consiste nel personalizzare il file di policy del livello di trust e aggiungere i permessi necessari. La soluzione è facile da implementare e non richiede modifiche al codice. Richiede, invece, che l amministratore abbia i diritti di modificare i file di policy della sicurezza. Da una mera prospettiva di sicurezza, non è un ottima soluzione, poiché si stanno semplicemente aggiungendo all intera applicazione i permessi necessari per un particolare metodo di una particolare pagina o di un assembly. Il secondo approccio richiede un po di refactoring ma porta a un codice migliore e più sicuro. L idea è di racchiudere in una sandbox il codice lato server e far delegare a componenti esterni (ad esempio, componenti serviced o programmi a riga di comando) l esecuzione dei compiti che vanno oltre l insieme di permessi dell applicazione. Ovviamente, il componente esterno verrà configurato perché abbia tutti i permessi richiesti. Nota Il sandboxing del codice è la sola opzione disponibile se la propria applicazione ASP.NET parzialmente trusted sta cercando di effettuare invocazioni in un assembly che non comprende l attributo AllowPartiallyTrustedCallers. Per ulteriori informazioni sulla programmazione nel caso di medium trust, si consulti la seguente URL: msdn2.microsoft.com/library/en-us/library/ms aspx.

13 Capitolo 17 Sicurezza in ASP.NET 817 Metodi di autenticazione ASP.NET In base al tipo di risorsa richiesta, IIS può o meno essere in grado di gestire da sé la richiesta. Se la risorsa richiede il coinvolgimento di ASP.NET (ad esempio, è un file.aspx), IIS passa la richiesta a ASP.NET unitamente al token di sicurezza dell utente, autenticato o anonimo. Ciò che accade in seguito dipende dalla configurazione ASP.NET. ASP.NET supporta tre tipi di metodi di autenticazione: Windows, Passport, e Forms. Una quarta possibilità è None, il cui significato è che ASP.NET non tenta neanche di eseguire una propria autenticazione e si affida completamente all autenticazione già effettuata da IIS. In questo caso, gli utenti anonimi possono connettersi e alle risorse si accede utilizzando l account ASP.NET di default. Utilizzando la sezione <authentication> del file web.config root, si sceglie il meccanismo di autenticazione ASP.NET. Le sottodirectory figlie ereditano la modalità di autenticazione scelta per l applicazione. Per default, la modalità di autenticazione è impostata a Windows. Esaminiamo brevemente l autenticazione Windows e Passport e riserviamo una più ampia trattazione per il metodo di autenticazione più comunemente utilizzato: l autenticazione Forms. Autenticazione Windows Quando si utilizza l autenticazione Windows, ASP.NET opera in combinazione con IIS. L autenticazione reale viene eseguita da IIS, che utilizza uno dei suoi metodi di autenticazione: Basic, Digest o Integrated Windows. Quando IIS ha autenticato l utente, passa il token di sicurezza a ASP.NET. Se si è in modalità di autenticazione Windows, ASP.NET non esegue alcun passo ulteriore e si limita a utilizzare il token IIS per autorizzare l accesso alle risorse. Tipicamente, si utilizza il metodo di autenticazione Windows negli scenari intranet quando gli utenti della propria applicazione dispongono di account Windows che possono essere autenticati solo dal Web server. Si supponga di aver configurato il Web server per operare con la modalità di autenticazione Integrated Windows e di aver disabilitato l accesso anonimo. L applicazione ASP.NET opera in modalità di autenticazione Windows. Che accade quando un utente si connette all applicazione? Per prima cosa, IIS autentica l utente (mostrando una finestra di dialogo se l account dell utente locale non corrisponde ad alcun account del Web server o del dominio trusted) e poi passa il token di sicurezza a ASP.NET. Utilizzo di ACL per autorizzare l accesso Il più delle volte, l autenticazione Windows viene utilizzata in combinazione con l autorizzazione dei file, attraverso il modulo HTTP FileAuthorizationModule. Le pagine specifiche all utente nell applicazione Web possono essere protette da accesso non autorizzato utilizzando le access control list (ACL) sul file. Quando ASP.NET sta per accedere a una risorsa, il modulo HTTP FileAuthorizationModule viene chiamato in azione. L autorizzazione file esegue un controllo ACL sui file ASP.NET utilizzando l identità del chiamante. Ciò significa che, ad esempio, l utente Joe non sarà mai in grado di accedere a una pagina.aspx la cui ACL non ha una voce che lo riguarda. Si noti, tuttavia, che l autorizzazione file non richiede l impersonazione a livello ASP.NET e, aspetto ancor più importante, opera indipendentemente dal fatto che il flag di

14 818 Parte III Infrastruttura ASP.NET impersonazione sia attivato. In questa affermazione si cela una buona e una cattiva notizia. Le buona notizia è che una volta impostata una ACL configurata in modo appropriato su una risorsa ASP.NET, il più è fatto. Nessuno sarà in grado di accedere alla risorsa senza permesso. Ma cosa accade nel caso di risorse non-asp.net come i file locali? Ad esempio, come si può proteggere una pagina HTML da un accesso non autorizzato? La prima considerazione è che una pagina HTML raramente necessita di essere ad accesso protetto. Se si deve proteggere una pagina, vuol dire che la pagina molto probabilmente esegue anche del codice lato server. Perciò, implementandola come.aspx è comunque più utile. Ciò detto, per design le pagine HTML non vengono protette da un accesso non autorizzato poiché non vengono processate dalla pipeline ASP.NET. Se si vuole proteggerla, la miglior cosa da fare è rinominare la pagina come.aspx in modo che sia processata dal runtime ASP.NET. Nota Le pagine HTML e altre risorse possono comunque essere protette utilizzando i permessi NTFS. Se vengono impostati dei vincoli particolari su un file utilizzando i permessi NTFS, non vi è modo che possa accedere al file chiunque sia privo degli opportuni diritti. In alternativa, si può rinominare la pagina con una estensione custom e scrivere una esigua estensione Internet Server Application Programming Interface (ISAPI), o un handler HTTP managed, per implementare un meccanismo di autorizzazione ad hoc. Gli handler HTTP vengono discussi nel Capitolo 18. Nota L autenticazione Windows funziona anche con l autorizzazione URL implementata dal modulo HTTP denominato URLAuthorizationModule. Questo modulo concede o nega l accesso alle risorse URL a certi utenti e ruoli. (Parleremo in seguito di autorizzazione URL quando discuteremo di autenticazione Forms). Autenticazione Passport L autenticazione Passport è un servizio di autenticazione centralizzato gestito da Microsoft. Passport fornisce un modo per autenticare gli utenti su tutti i siti che partecipano all iniziativa. Gli utenti devono effettuare un singolo logon e, se autenticato con esito positivo, possono liberamente spostarsi in tutti i siti membri. Oltre al servizio di singolo logon, Passport offre anche dei servizi di base di profilazione ai siti membri. ASP.NET fornisce il modulo HTTP PassportAuthenticationModule per impostare l autenticazione per le applicazioni Web ospitate da siti membri Passport. Quando una richiesta HTTP giunge ad un sito Web Passport-abilitato, il modulo HTTP verifica se o meno la richiesta contiene un ticket Passport valido. In caso negativo, il Web server restituisce il codice di stato 302 e redirige il client al servizio Passport Logon. La query string contiene

15 Capitolo 17 Sicurezza in ASP.NET 819 le informazioni opportunamente crittografate sulla richiesta originale. Il client invia una richiesta GET al server di logon e passa la query string fornita. A questo punto, il server di logon Passport presenta al client un form HTML di logon. Dopo che l utente ha compilato il form, il form viene postato nuovamente al server di logon su un canale sicuro SSL. Il server di logon utilizza le informazioni del form per autenticare l utente e, in caso di esito positivo, crea un ticket Passport. Successivamente, l utente viene rediretto all URL originale e nella query string viene passato il ticket, crittografato. Infine, il browser esegue l istruzione di redirect e richiede nuovamente la risorsa originale, protetta da Passport. Questa volta, tuttavia, la richiesta contiene un ticket valido e il modulo PassportAuthenticationModule permetterà alla richiesta di passare. Nota Il.NET Framework 3.0 contiene un nuova tecnologia che può essere utilizzata con siti Web ASP.NET per autenticare gli utenti: Windows CardSpace. Qualsiasi pagina che comprende l oggetto Identity Selector, utilizza le carte di identità dell utente connesso per inviare le credenziali al server. Ciascuno può gestire le proprie carte utilizzando l applet Windows CardSpace del Pannello di Controllo di una macchina Windows Vista (o di qualsiasi altra macchina client dotata del.net Framework 3.0 o versioni successive). Identity Selector è un tag <object> di tipo application/x-informationcard. Richiedendo la proprietà value di questo oggetto, si impone a un browser abilitato (ad es., Internet Explorer 7.0) di mostrare l applet CardSpace. L utente poi seleziona la carta corretta da inviare. La pagina di login lato server accederà poi al contenuto della carta e farà ogni controllo necessario per autorizzare la richiesta. Se ampiamente accettato, Windows CardSpace sarebbe lo strumento perfetto di autenticazione su Internet. Per ulteriori informazioni, si può leggere la documentazione MSDN online di Windows CardSpace. Un buon punto da cui partire è il sito Web di Windows CardSpace Utilizzo dell autenticazione Forms Sia l autenticazione Windows sia l autenticazione Passport sono raramente pratiche per le applicazioni Internet reali. L autenticazione Windows si basa sugli account Windows e sui token ACL NTFS e, in quanto tale, assume che i client si stiano connettendo da macchine Windows. Utile ed efficace negli scenari intranet e probabilmente in alcuni scenari extranet, l autenticazione Windows è semplicemente non realistica nelle situazioni più comuni poiché agli utenti dell applicazione Web è richiesto un account Windows nel dominio dell applicazione. La stessa conclusione si applica all autenticazione Passport, benché per motivi differenti. Passport non è gratuito, richiede l implementazione di serie misure di sicurezza (anch esse non gratuite e non necessariamente necessarie su tutti i siti), e ha senso prevalentemente per siti Web di e-commerce e siti in co-branding. Allora qual è il meccanismo di autenticazione ideale per i reali sviluppatori Web? Una best-practice di programmazione Web raccomanda di inserire del codice relativamente standard all inizio di ciascuna pagina non pubblica e di redirigere l utente a una pagina di login. Nella pagina di login, all utente vengono richieste le credenziali e viene rediretto alla pagina richiesta in origine, se autenticato con esito positivo. Questo codice non

16 820 Parte III Infrastruttura ASP.NET è esattamente di difficoltà stratosferica, ma è comunque codice da scrivere da sé e da riutilizzare ripetutamente. L autenticazione Forms è semplicemente l infrastruttura ASP.NET nativa per implementare il suddetto pattern di login. Ad oggi, l autenticazione Forms è la scelta ideale (direi la sola scelta) ogni qualvolta sia necessario raccogliere le credenziali utente e processarle internamente: ad esempio, rispetto a un database di account utente. Il pattern di login implementato dall autenticazione Forms non sembra radicalmente differente dall autenticazione Windows e Passport. La principale differenza è che con l autenticazione Forms tutto accade sotto il rigido controllo dell applicazione. Per impostare una applicazione ASP.NET all utilizzo della autenticazione Forms si interviene nel file web.config root, inserendo il seguente script: <system.web> <authentication mode= Forms > <forms loginurl= login.aspx /> </authentication> <authorization> <deny users=? /> </authorization> </system.web> La sezione <authentication> indica l URL del form di login definito dall utente. ASP.NET visualizza il form solo agli utenti a cui è stato esplicitamente negato l accesso nella sezione <authorization>. Il simbolo? indica qualsiasi utente anonimo non autenticato. Si noti che qui l utente anonimo non è l utente anonimo di IIS ma è semplicemente un utente che non è stato autenticato attraverso il vostro form di login. Gli utenti bloccati vengono rediretti alla pagina di login, dove gli viene richiesto di inserire le credenziali. Nota Il meccanismo di autenticazione Forms protegge qualsiasi risorsa ASP.NET posizionata in una cartella per cui è abilitata l autenticazione e l autorizzazione Forms. Si noti che vengono protetti solo i tipi di risorsa gestiti esplicitamente da ASP.NET. L elenco comprende i file.aspx,.asmx e.ashx, ma non le semplici pagine HTML o le pagine ASP classico. In IIS 7.0, tuttavia, vengono forniti gli strumenti per modificare ciò impostando un file web.config a livello di Web server in cui si assegnano nuove risorse all handler HTTP standard ASP.NET. Flusso di controllo dell autenticazione Forms L autenticazione basata su Form è regolata da un modulo HTTP implementato nella classe FormsAuthenticationModule. Il comportamento del componente è pilotato dal contenuto del file web.config. Quando il browser tenta di accedere a una risorsa protetta, il modulo entra in azione e tenta di individuare un ticket di autenticazione del chiamante. In ASP.NET 1.x, un ticket è semplicemente un cookie con un nome particolare (configurabile).

17 Capitolo 17 Sicurezza in ASP.NET 821 In ASP.NET 2.0 e nelle versioni successive, può essere configurato per essere un valore inglobato nell URL (autenticazione Forms senza cookie). Se non viene trovato un ticket valido, il modulo redirige la richiesta a una pagina di login. Le informazioni sulla pagina di provenienza vengono poste nella query string. La pagina di login viene quindi visualizzata. Il programmatore crea questa pagina, che, come minimo, contiene le textbox per il nome utente e la password e un pulsante per l invio delle credenziali. L handler dell evento clic del pulsante valida le credenziali utilizzando un algoritmo e un datastore specifici dell applicazione. Se le credenziali vengono autenticate, il codice utente redirige il browser all URL originale. L URL originale è allegata alla query string della richiesta della pagina di login, come è mostrato qui: Autenticare un utente significa che un ticket di autenticazione viene inviato allegato alla richiesta. Quando il browser effettua la seconda richiesta di quella pagina, il modulo HTTP recupera il ticket di autenticazione e permette alla richiesta di passare. Vediamo come opera in pratica l autenticazione basata su form e consideriamo uno scenario in cui agli utenti non è permesso connettersi in modo anonimo alle pagine dell applicazione. L utente digita l URL della pagina, ad esempio welcome.aspx, e procede. Di conseguenza, il modulo HTTP redirige alla pagina di login qualsiasi utente privo del ticket di autenticazione, come è mostrato nella Figura Figura 17-3 La pagina di login dell applicazione d esempio. Importante Esistono dei problemi intrinseci di sicurezza che si manifestano con l autenticazione Forms relativa al fatto che i dati vengono trasmessi come testo in chiaro. Sfortunatamente, con l attuale tecnologia dei browser questi potenziali problemi di sicurezza possono essere rimossi solo ricorrendo ai canali sicuri (HTTPS). Tornerò su questo argomento in seguito nel paragrafo Problemi generali di sicurezza.

18 822 Parte III Infrastruttura ASP.NET Raccolta delle credenziali attraverso il login Il layout di una pagina di login è pressoché sempre lo stesso: un paio di textbox per inserire nome utente e password, un pulsante per confermare, e probabilmente un etichetta per visualizzare i messaggi d errore. Tuttavia, si può renderla anche più complessa, se necessario, e aggiungere anche degli elementi grafici appropriati. L utente inserisce le credenziali, tipicamente in modo casesensitive, e poi clicca il pulsante per effettuare il logon. Quando la pagina di login effettua il postback, viene eseguito il seguente codice: void LogonUser(object sender, EventArgs e) { string user = username.text; string pswd = password.text; } // Autenticazione personalizzata bool bauthenticated = AuthenticateUser(user, pswd); if (bauthenticated) FormsAuthentication.RedirectFromLoginPage(user, false); else errormsg.text = Sorry, yours seems not to be a valid account. ; L handler dell evento recupera le stringhe digitate nei campi nome utente e password e invoca una funzione locale denominata AuthenticateUser. La funzione verifica le credenziali fornite e restituisce un valore Boolean. Se l utente è stato autenticato con esito positivo, il codice invoca il metodo statico RedirectFromLoginPage della classe FormsAuthentication per informare il browser che è il momento di inviare una nuova richiesta alla pagina originale. Il metodo RedirectFromLoginPage redirige un utente autenticato nuovamente all URL richiesta in origine. Questo metodo ha due overload con i seguenti prototipi: public static void RedirectFromLoginPage(string, bool); public static void RedirectFromLoginPage(string, bool, string); Il primo argomento è il nome dell utente da memorizzare nel ticket di autenticazione. Il secondo argomento è un valore Boolean che denota la durata del cookie, eventuale, che viene creato per il ticket di autenticazione. Se questo argomento è true, al cookie viene attribuita una durata pari al numero di minuti impostato dall attributo timeout (che per default è 30 minuti). In questo modo, si ottiene un cookie che persiste tra le sessioni del browser. Altrimenti il vostro cookie di autenticazione durerà solo per la sessione corrente. Infine, il terzo argomento (opzionale) specifica il percorso del cookie. Autenticazione dell utente L algoritmo di autenticazione, cioè il codice all interno del metodo AuthenticateUser visto prima, è compito dello sviluppatore. Ad esempio, si potrebbero voler controllare le credenziali su un database o su qualsiasi altro dispositivo di memorizzazione definito dall utente. Il listato seguente mostra una funzione che confronta nome utente e password con le colonne firstname e lastname della

19 Capitolo 17 Sicurezza in ASP.NET 823 tabella Northwind Employees di SQL Server: private bool AuthenticateUser(string username, string pswd) { // Qui esegue l autenticazione string connstring =... ; string cmdtext = SELECT COUNT(*) FROM employees + WHERE firstname=@user AND lastname=@pswd ; } int found = 0; using(sqlconnection conn = new SqlConnection(connString)) { SqlCommand cmd = new SqlCommand(cmdText, conn); SqlDbType.VarChar, 10).Value = username; SqlDbType.VarChar, 20).Value = pswd; conn.open(); found = (int)cmd.executescalar(); conn.close(); } return (found > 0); La query è configurata per restituire un intero che rappresenta il numero di righe della tabella che corrispondono al nome utente e alla password specificata. Si noti l utilizzo dei parametri tipizzati e dimensionati nel comando SQL come forma di difesa contro una possibile iniezione di codice subdolo. Si noti anche che il codice SQL appena mostrato non supporta le password forti poiché l operatore SQL = della clausola WHERE non esegue confronti case-sensitive. Per prendere provvedimenti su ciò, si dovrà riscrivere il comando come segue: SELECT COUNT(*) FROM employees WHERE CAST(RTRIM(firstname) AS VarBinary)=CAST(RTRIM(@user) AS VarBinary) AND CAST(RTRIM(lastname) AS VarBinary)=CAST(RTRIM(@pswd) AS VarBinary) L operatore CAST converte il valore nella relativa rappresentazione binaria, mentre l operatore RTRIM rimuove gli spazi in coda. La Figura 17-4 mostra la pagina dell applicazione dopo che l utente è stato autenticato con esito positivo.

20 824 Parte III Infrastruttura ASP.NET Figura 17-4 L utente è stato autenticato, e il nome viene mostrato nell interfaccia utente. La pagina welcome.aspx è costituita dal seguente codice sorgente, abbastanza semplice: <%@ Page Language= C# CodeFile= Welcome.aspx.cs Inherits= Welcome %> <html><body> <form id= form1 runat= server > <h1>welcome, <%=User.Identity.Name %></h1> </form> </body></html> Sign-out Mentre un login esplicito è sempre richiesto dai siti Web che richiedono una autenticazione, un logout esplicito è meno comune ma nondimeno legittimo. Il modulo di autenticazione Forms fornisce un metodo esplicito per effettuare il sign-out. Il metodo SignOut della classe FormsAuthentication non ha argomenti e reimposta il ticket di autenticazione. In particolare, quando vengono utilizzati i cookie, il metodo SignOut rimuove il ticket corrente dalla collection Cookies dell oggetto HttpResponse corrente e lo sostituisce con un cookie vuoto e scaduto. Dopo l invocazione a SignOut, si può redirigere l applicazione ad un altra pagina: ad esempio, alla home page. Per farlo, non è necessario redirigere il browser, ma finché la pagina è pubblicamente accessibile, si può utilizzare il più efficiente metodo Server.Transfer che abbiamo descritto nel Capitolo 14. void Signout(object sender, EventArgs e) { FormsAuthentication.SignOut(); Server.Transfer( home.aspx ); } A partire da ASP.NET 2.0, la classe FormsAuthentication ha un nuovo metodo, RedirectToLoginPage, che fornisce la funzionalità descritta, eccetto che utilizza Response.Redirect invece di Server.Transfer. Abbiamo trattato appena i fondamenti dell autenticazione Forms, ma non abbiamo ancora trattato alcun dettaglio dell API di programmazione che troviamo in ASP.NET. Prima di passare a ciò, è importante dare un occhiata ai metodi della classe FormsAuthentication