Passaggio di pianificazione 4: Pianificare la sicurezza delle applicazioni
di Keith Newman e Robert McMurray
In questa fase della creazione del sito Web occorre considerare le esigenze dell'applicazione ASP.NET in materia di sicurezza. Le sezioni seguenti descrivono le impostazioni di sicurezza dell'applicazione disponibili in IIS 8:
4.1. Isolare le applicazioni Web
Uno dei modi più efficaci per migliorare la sicurezza dell'applicazione Web consiste nell'isolarla da altre applicazioni nel server Web. Un pool di applicazioni dispone del proprio processo di lavoro che elabora le richieste ed esegue il codice dell'applicazione. Il processo di lavoro ha un identificatore di sicurezza (SID) e ogni pool di applicazioni dispone di un'identità univoca. Per impostazione predefinita, quando si crea un'applicazione Web, viene anche creato un nuovo pool di applicazioni con lo stesso nome dell'applicazione. Se le applicazioni Web vengono tenute in pool di applicazioni separati, è possibile isolarle tra loro.
L'isolamento delle applicazioni Web comporta quanto segue:
- Isolamento del sito: diverse applicazioni separate in siti diversi con pool di applicazioni diversi.
- Privilegio minimo: eseguire il processo di lavoro come identità con privilegi limitati (identità del pool di applicazioni virtuali) univoca per ogni sito.
- Isolamento temporaneo: configurare una cartella temporanea separata ASP.NET per sito e concedere solo l'accesso all'identità del processo appropriata.
- Isolamento del contenuto: verificare di aver impostato un elenco di controllo di accesso (ACL) per ogni radice del sito per consentire l'accesso soltanto all'identità del processo appropriata.
Suggerimento
È consigliabile ospitare il sito Web e il contenuto dell'applicazione Web su un'unità diversa dall'unità di sistema (C:).
4.2. Livelli di attendibilità .NET
Il livello di attendibilità di un'applicazione determina le autorizzazioni concesse dai criteri di sicurezza dall'accesso di codice ASP.NET. Questi criteri definiscono due categorie di attendibilità: totale e parziale. Un'applicazione che dispone di autorizzazioni di attendibilità totale può accedere a tutti i tipi di risorsa in un server ed eseguire operazioni privilegiate. Le applicazioni con attendibilità totale sono interessate solo dalle impostazioni di sicurezza del sistema operativo.
Le applicazioni Web con attendibilità parziale sono applicazioni senza attendibilità totale e con un set limitato di autorizzazioni di accesso al codice. Queste applicazioni hanno pertanto limiti di accesso alle risorse protette e di esecuzione di altre operazioni privilegiate. Alcune autorizzazioni vengono negate alle applicazioni parzialmente attendibili. Non è quindi possibile accedere direttamente alle risorse che richiedono tali autorizzazioni. Altre autorizzazioni vengono concesse in modo limitato, quindi le risorse che richiedono tali autorizzazioni potrebbero essere accessibili, ma con alcune limitazioni. Ad esempio, l'autorizzazione limitata di I/O di file consente all'applicazione di accedere al file system, ma soltanto nelle directory sotto la radice della directory virtuale dell'applicazione.
Configurando un'applicazione Web o un servizio Web per l'attendibilità parziale, è possibile limitare la capacità dell'applicazione di accedere alle risorse di sistema fondamentali o alle risorse appartenenti ad altre applicazioni Web. Concedendo soltanto le autorizzazioni richieste dall'applicazione e nient'altro, è possibile compilare applicazioni Web con privilegi minimi e limitare il danno potenziale nell'eventualità in cui l'applicazione Web venga compromessa da un attacco di tipo code injection.
L'elenco seguente illustra le restrizioni associate a ogni livello di attendibilità:
- Le applicazioni con attendibilità totale hanno accesso illimitato a tutti i tipi di risorse e possono eseguire operazioni privilegiate.
- Le applicazioni con un'attendibilità elevata, media, bassa o minima non sono in grado di chiamare il codice non gestito o i componenti serviti, scrivere nel registro eventi, accedere alle code di Accodamento messaggi o alle origini dati OLE DB.
- Le applicazioni con attendibilità elevata hanno accesso illimitato al file system.
- Le applicazioni con attendibilità media hanno un accesso limitato al file system e possono accedere soltanto ai file nella propria gerarchia delle directory dell'applicazione.
- Le applicazioni con attendibilità bassa o minima non possono accedere ai database di SQL Server.
- Le applicazioni con attendibilità minima non possono accedere ad alcuna risorsa.
4.3. Autenticazione .NET
L'autenticazione consente di confermare l'identità dei client che richiedono l'accesso ai siti e alle applicazioni. Quando l'autenticazione è abilitata, IIS 8 usa le credenziali dell'account fornite dall'utente per determinare le autorizzazioni concesse dall'utente e le risorse a cui l'utente può accedere.
Questa sezione illustra le modalità di autenticazione specifiche delle applicazioni ASP.NET.
Autenticazione basata su form ASP.NET
L'autenticazione basata su form usa il reindirizzamento sul lato client per inoltrare gli utenti non autenticati a un form HTML in cui possono inserire le credenziali, generalmente un nome utente e una password. Dopo la convalida delle credenziali, gli utenti vengono reindirizzati alla pagina che avevano richiesto inizialmente. L'autenticazione basata su form usa spesso i cookie per passare le credenziali utente tra il server e il browser client.
Le sezioni seguenti forniscono le informazioni necessarie per pianificare l'aggiunta dell'autenticazione basata su form al sito:
Nozioni di base sull'autenticazione basata su form
L'autenticazione basata su form ASP.NET è ideale per siti o applicazioni in server Web pubblici che ricevono un numero elevato di richieste. Questa modalità di autenticazione consente di gestire la registrazione e l'autenticazione client a livello di applicazione, invece di usare i meccanismi di autenticazione forniti dal sistema operativo.
Importante
Poiché l'autenticazione basata su form invia il nome utente e la password al server Web come testo non crittografato, usare la crittografia SSL (Secure Sockets Layer) per la pagina di accesso e per tutte le altre pagine dell'applicazione ad eccezione della home page. Per informazioni su SSL, vedere 4.5. Comunicazione TLS/SSL.
L'autenticazione basata su form consente agli utenti di accedere usando le identità di un database delle appartenenze ASP.NET. Questo metodo di autenticazione usa il reindirizzamento a una pagina di accesso HTML per verificare l'identità dell'utente. È possibile configurare l'autenticazione basata su form a livello di sito o di applicazione.
L'autenticazione basata su form è utile per i motivi seguenti:
- Consente di usare un archivio dati personalizzato, ad esempio un database di SQL Server, oppure Active Directory per l'autenticazione.
- Si integra facilmente con un'interfaccia utente Web.
- I client possono usare qualsiasi browser.
Se si desidera usare ruoli di appartenenza per l'autorizzazione, usare l'autenticazione basata su form o un metodo di autenticazione personalizzato simile.
Importante
Se si seleziona l'autenticazione basata su form, non è possibile usare contemporaneamente altri metodi di autenticazione basati su richiesta di verifica.
Per impostazione predefinita, l'URL di accesso per l'autenticazione basata su form è Login.aspx. È possibile creare una pagina di accesso univoca per i client che visitano un sito o un'applicazione. Potrebbe essere necessario, ad esempio, raccogliere informazioni specifiche dai visitatori o consentire l'appartenenza a pagine specifiche del sito o ad applicazioni selezionate.
Il valore di timeout predefinito per l'autenticazione basata su form è 30 minuti. È consigliabile impostare il valore di timeout su un periodo di tempo più breve per ridurre la durata della sessione e la probabilità di attacchi di riproduzione di cookie.
Cookie di autenticazione
I cookie di autenticazione vengono usati come token per verificare che un client abbia accesso ad alcune o tutte le pagine di un'applicazione. I cookie di personalizzazione contengono invece impostazioni specifiche dell'utente che determinano l'esperienza utente riguardo a un'applicazione o un sito specifico.
Importante: poiché i cookie di autenticazione vengono passati tra client e server insieme a ogni richiesta, proteggere sempre i cookie di autenticazione usando Secure Sockets Layer (SSL). Per informazioni su SSL, vedere 4.5. Comunicazione TLS/SSL.
I cookie consentono di tenere traccia dei visitatori di un sito in modo più efficace delle stringhe di query, in quanto non richiedono il reindirizzamento. Questi elementi sono tuttavia dipendenti dal browser, e alcuni browser non li supportano. L'uso dell'autenticazione basata su cookie non è inoltre sempre possibile in quanto alcuni utenti disabilitano il supporto dei cookie nei propri browser.
Per impostazione predefinita, il nome del cookie per le applicazioni ASP.NET è .ASPXAUTH. È tuttavia possibile usare un nome e un percorso di cookie univoci per ogni applicazione. In questo modo è possibile impedire agli utenti autenticati per un'applicazione di essere autenticati per altre applicazioni in un server Web.
È possibile scegliere una delle modalità di cookie seguenti per il sito o l'applicazione:
| Mode | Descrizione |
|---|---|
| Utilizza cookie | I cookie vengono sempre usati, indipendentemente dal dispositivo. |
| Non utilizzare cookie | I cookie non vengono usati. |
| Rilevamento automatico | I cookie vengono usati se supportati dal profilo del dispositivo. In caso contrario, non vengono usati cookie. Per i browser desktop che supportano i cookie, in ASP.NET viene eseguito un controllo per determinare se i cookie sono abilitati. Questa è l'impostazione predefinita. |
| Utilizza profilo del dispositivo | I cookie vengono usati se supportati dal profilo del dispositivo. In caso contrario, non vengono usati cookie. ASP.NET non verifica che i cookie siano abilitati nei dispositivi che li supportano. Questa impostazione è l'impostazione predefinita per IIS 8. |
La modalità di protezione dei cookie definisce la funzione eseguita da un cookie di autenticazione basata su form per un'applicazione specifica. La tabella seguente illustra le modalità di protezione dei cookie che è possibile definire:
| Mode | Descrizione |
|---|---|
| Crittografia e convalida | Specifica che l'applicazione usa la crittografia e la convalida dei dati per proteggere il cookie. Questa opzione usa l'algoritmo di convalida dei dati configurato (basato sulla chiave del computer). Per la crittografia viene usato l'algoritmo Triple DES (3DES), se disponibile e se la chiave è sufficientemente lunga (almeno 48 byte). Questa impostazione rappresenta il valore predefinito e consigliato. |
| Nessuno | Specifica che la crittografia e la convalida sono disabilitate per i siti che usano cookie solo per la rappresentazione e che hanno requisiti di sicurezza limitati. Sebbene non sia consigliabile usare i cookie in questo modo, si tratta del metodo che utilizza il minor numero di risorse per abilitare la rappresentazione tramite .NET Framework. |
| Crittografia | Specifica che il cookie viene crittografato tramite Triple DES o DES, ma non viene sottoposto a convalida dei dati. I cookie usati in questo modo potrebbero essere esposti ad attacchi di testo non crittografato. |
| Convalida | Specifica che uno schema di convalida verifica che il contenuto di un cookie crittografato non sia stato modificato durante il passaggio. |
Importante
Per motivi di sicurezza, tenere i cookie di crittografia e di convalida separati. L'eventuale furto dei cookie di crittografia rappresenta un rischio per la sicurezza maggiore rispetto a quello dei cookie di convalida.
Se un'applicazione contiene oggetti che i client richiedono di frequente, è possibile migliorare le prestazioni dell'applicazione memorizzando nella cache tali oggetti. Se l'utente accede all'oggetto memorizzato nella cache prima del timeout del cookie di autenticazione, IIS 8 consente all'oggetto memorizzato nella cache di rimanere nella cache e il timer viene reimpostato. Tuttavia, se l'utente non accede all'oggetto memorizzato nella cache durante tale periodo, IIS 8 rimuove l'oggetto memorizzato nella cache.
Attivare questa impostazione quando:
- La quantità di memoria disponibile per la memorizzazione nella cache è limitata.
- Sono presenti numerosi oggetti da memorizzare nella cache, in quanto questa impostazione consente di conservare nella cache solo gli oggetti richiesti con maggiore frequenza.
Nota
È possibile specificare il numero di minuti prima del timeout di un cookie di autenticazione in Timeout del cookie di autenticazione (in minuti).
Autenticazione basata sulla rappresentazione ASP.NET
Usare la rappresentazione ASP.NET quando si vuole eseguire l'applicazione ASP.NET in un contesto di sicurezza diverso da quello predefinito per le applicazioni ASP.NET.
Se si abilita la rappresentazione per un'applicazione ASP.NET, tale applicazione può essere eseguita in uno dei due contesti diversi: come l'utente autenticato da IIS 8 o come account arbitrario configurato. Se ad esempio si usasse l'autenticazione anonima e si scegliesse di eseguire l'applicazione ASP.NET come utente autenticato, l'applicazione verrebbe eseguita con un account configurato per gli utenti anonimi (in genere IUSR). Analogamente, se si sceglie di eseguire l'applicazione in un account arbitrario, viene eseguita nel contesto di sicurezza configurato per l'account.
Per impostazione predefinita, la rappresentazione ASP.NET è disabilitata. Se si abilita la rappresentazione, l'applicazione ASP.NET viene eseguita nel contesto di sicurezza dell'utente autenticato da IIS 8.
4.4. Impostazioni delle chiavi del computer
Le chiavi del computer proteggono i dati dei cookie dell'autenticazione basata su form e i dati sullo stato della visualizzazione a livello di pagina, oltre a verificare l'identificazione dello stato delle sessioni out-of-process. ASP.NET usa i tipi di chiavi del computer seguenti:
- Una chiave di convalida consente di calcolare un codice MAC (Message Authentication Code) per confermare l'integrità dei dati. Questa chiave viene aggiunta al cookie di autenticazione basata su form o allo stato di visualizzazione di una pagina specifica.
- Una chiave di decrittografia consente di crittografare e decrittografare i ticket dell'autenticazione basata su form e lo stato della visualizzazione.
IIS 8 consente di configurare le impostazioni di convalida e crittografia e generare chiavi del computer da usare con i servizi applicazioni ASP.NET, ad esempio lo stato di visualizzazione, l'autenticazione dei moduli, l'appartenenza, i ruoli e l'identificazione anonima.
Prima di generare le chiavi del computer per l'applicazione, prendere le seguenti decisioni di progettazione:
- Decidere quale metodo di convalida usare: AES, MD5, SHA1 (impostazione predefinita), TripleDES, HMACSHA256, HMACSHA384 o HMACSHA512.
- Decidere quale metodo di crittografia usare: Auto (impostazione predefinita), AES, TripleDES o DES.
- Decidere se generare la chiave di convalida automaticamente in fase di esecuzione.
- Decidere se generare una chiave di convalida univoca per ogni applicazione.
- Decidere se generare la chiave di decrittografia automaticamente in fase di esecuzione.
- Decidere se generare una chiave di decrittografia univoca per ogni applicazione.
4.5. Comunicazioni TLS/SSL
Transport Layer Security (TLS) e il suo predecessore, Secure Sockets Layer (SSL), sono protocolli che garantiscono al sito Web la sicurezza delle comunicazioni. È possibile usare TLS/SSL per autenticare i server e i client, quindi per crittografare i messaggi tra le parti autenticate.
Nel processo di autenticazione, un client TLS/SSL invia un messaggio a un server TLS/SSL e il server risponde con le informazioni necessarie per autenticare se stesso. Il client e il server eseguono un ulteriore scambio di chiavi di sessione e le comunicazioni di autenticazione terminano. Al termine dell'autenticazione, può iniziare la comunicazione protetta con SSL tra il server e il client tramite le chiavi di crittografia simmetriche stabilite durante il processo di autenticazione.
Per configurare TSL/SSL per il sito Web, eseguire le operazioni seguenti:
- Ottenere un certificato del server da un'Autorità di certificazione (CA). Vedere Certificati del server.
- Aggiungere un binding SSL al sito. Vedere Binding SSL.
- Impostare IIS per richiedere SSL per il sito. Vedere Richiedere SSL per il sito.
- Provare a usare i certificati client del sito. Vedere Certificati client.
Certificati del server
È possibile ottenere un certificato del server da un'Autorità di certificazione (CA). L'assegnazione di un certificato del server da parte di un'Autorità di certificazione costituisce un passaggio del processo di configurazione di Secure Sockets Layer (SSL) o Transport Layer Security (TLS). È possibile ottenere un certificato del server da una CA di terze parti, che potrebbe richiedere una prova dell'identità prima di rilasciarlo. È inoltre possibile emettere i propri certificati del server usando una CA online, ad esempio Servizi certificati Microsoft.
I certificati digitali sono file elettronici il cui funzionamento è analogo a quello di una password online per la verifica dell'identità di un utente o di un computer. Vengono usati per creare il canale crittografato SSL usato per le comunicazioni client. Un certificato è una dichiarazione digitale emessa da un'Autorità di certificazione (CA) che si fa garante dell'identità del titolare del certificato e consente alle parti di comunicare in modo sicuro tramite la crittografia.
I certificati digitali svolgono le seguenti funzioni:
- Autenticano che i loro titolari, siti Web e anche risorse di rete, ad esempio router, sono veramente chi o cosa dichiarano di essere.
- Proteggono i dati scambiati online da furti o alterazioni.
I certificati digitali vengono emessi da una CA di terze parti attendibile o da un'infrastruttura a chiave pubblica (PKI) di Microsoft Windows mediante Servizi certificati, oppure possono essere autofirmati. Ogni tipo di certificato presenta vantaggi e svantaggi. Ogni tipo di certificato digitale è inalterabile e non può essere contraffatto.
I certificati possono essere emessi per diversi scopi, tra cui l'autenticazione utente Web, l'autenticazione server Web, S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol Security), TLS (Transport Layer Security) e la firma del codice.
Un certificato contiene una chiave pubblica che viene associata all'identità della persona, del computer o del servizio che possiede la chiave privata corrispondente. La chiave pubblica e quella privata vengono usate dal client e dal server per crittografare i dati prima di trasmetterli. Per gli utenti, i computer e i servizi basati su Windows, l'attendibilità di una CA è stabilita quando esiste una copia del certificato radice nell'archivio dei certificati radice attendibili e il certificato contiene un percorso di certificazione valido. Per essere valido, il certificato non deve essere stato revocato e il periodo di validità non deve essere scaduto.
Binding SSL
È possibile assegnare più binding a un sito quando si dispone di contenuto del sito che soddisfa scopi diversi o per cui è necessario usare un altro protocollo. Un sito per il commercio elettronico, ad esempio, potrebbe includere un'applicazione che richiede agli utenti di accedere a un account per acquistare i prodotti. La società ospita il sito tramite HTTP, ma gli utenti devono accedere al proprio account in una pagina HTTPS. In questo esempio il sito disporrebbe di due binding: uno per la parte HTTP e uno per la parte HTTPS.
Gestione IIS non consente l'aggiunta immediata di binding per protocolli diversi da HTTP e HTTPS. Se si vuole aggiungere un binding per un protocollo diverso, ad esempio un protocollo supportato da Windows Communication Foundation (WCF), usare uno degli altri strumenti di amministrazione. Se tuttavia si scarica e installa il nuovo server FTP (File Transfer Protocol) di IIS, è possibile aggiungere binding FTP mediante Gestione IIS. Potrebbero essere disponibili per il download altri moduli o funzionalità di terze parti che consentono di estendere l'interfaccia utente.
Richiedere SSL per il sito
La crittografia SSL (Secure Sockets Layer) protegge le informazioni riservate o personali inviate tra un client e un server. Quando SSL è abilitato, i client remoti accedono al sito tramite URL che iniziano con https://.
Per abilitare le impostazioni SSL, configurare prima un certificato del server, quindi creare un binding HTTPS. Richiedere quindi la crittografia SSL (Secure Sockets Layer) in una o più delle circostanze seguenti:
- Quando contenuto riservato o personale nel server deve essere protetto da un canale crittografato.
- Quando si vuole che gli utenti siano in grado di verificare l'identità del server prima di trasmettere informazioni personali.
- Quando si desidera usare certificati client per autenticare i client che accedono al server.
Certificati client
Se si vuole che i client verifichino l'identità prima di accedere al contenuto nel server Web, configurare i certificati client. Per impostazione predefinita, i certificati client vengono ignorati.
Per poter configurare un certificato client nel sito Web, configurare un certificato server e creare un binding HTTPS per abilitare le impostazioni SSL (Secure Sockets Layer).
Se si vuole che tutti i client verifichino l'identità, specificare che i certificati client sono obbligatori. Se alcuni client possono accedere al contenuto senza prima verificare l'identità, specificare che i certificati client sono accettati.