Protezione dei ruoli
Aggiornamento: novembre 2007
La funzionalità di gestione dei ruoli consente di controllare il sistema di autorizzazioni per l'applicazione tramite categorie create liberamente, definite "ruoli". Assegnando gli utenti ai ruoli, è possibile controllare l'accesso alle diverse aree o funzionalità dell'applicazione Web in base a un ruolo, in alternativa o congiuntamente al nome utente. In un'applicazione aziendale ad esempio possono essere creati ruoli per i manager, gli impiegati, i direttori e così via, ognuno con privilegi distinti.
Gli utenti possono appartenere a più ruoli. Se ad esempio il sito è un forum di discussione, alcuni utenti potrebbero avere sia il ruolo di membro che quello di moderatore. Se a ogni ruolo vengono assegnati privilegi differenti per il sito, un utente con tutti e due i ruoli avrà entrambi gli insiemi di privilegi.
L'adozione delle procedure ottimali per la codifica e la configurazione può migliorare la sicurezza dell'applicazione, ma è altrettanto importante mantenere il server applicazioni costantemente aggiornato in base alle ultime patch di sicurezza per Microsoft Windows e Internet Information Services (IIS) e a tutte le patch per Microsoft SQL Server, Active Directory o altre origini dati dei ruoli.
Per informazioni più dettagliate sulle procedure ottimali per la scrittura di codice sicuro e la protezione delle applicazioni, vedere il libro "Writing Secure Code" di Michael Howard e David LeBlanc, nonché la guida fornita da Microsoft Patterns and Practices all'indirizzo https://www.microsoft.com/resources/practices/default.mspx (informazioni in lingua inglese).
Protezione delle impostazioni di configurazione della gestione dei ruoli
Nelle applicazioni ASP.NET la funzionalità di gestione dei ruoli è disattivata per impostazione predefinita, in modo da aumentare la sicurezza delle applicazioni che non utilizzano la gestione dei ruoli. Quando la funzionalità è attivata, nelle impostazioni di configurazione predefinite sono specificati i valori più sicuri. Per informazioni sulle impostazioni di configurazione della gestione dei ruoli e sui relativi valori predefiniti, vedere Elemento roleManager (schema delle impostazioni ASP.NET).
Sicurezza dei valori di configurazione
Quando vengono archiviate informazioni riservate in un file di configurazione relativo a un'applicazione, i valori riservati devono essere crittografati utilizzando la configurazione protetta. Tra le informazioni particolarmente riservate sono incluse le chiavi di crittografia nell'elemento di configurazione machineKey e le stringhe di connessione all'origine dati nell'elemento di configurazione connectionStrings. Per ulteriori informazioni, vedere Crittografia delle informazioni di configurazione utilizzando la configurazione protetta.
Chiavi di crittografia sicure e generazione di un hash
È consigliabile proteggere i nomi dei ruoli memorizzati nella cache di un cookie impostando l'attributo cookieProtection dell'elemento roleManager su All. I valori delle chiavi di crittografia relativi all'algoritmo di crittografia specificato vengono archiviati nell'elemento di configurazione machineKey. Per una crittografia avanzata, specificare un chiave corrispondente a un valore generato in modo casuale di lunghezza appropriata per l'algoritmo di crittografia selezionato.
In un server contenente più applicazioni è opportuno definire chiavi di crittografia univoche per ogni applicazione. Un'alternativa meno sicura consiste nel definire una sola chiave di crittografia e specificare l'opzione IsolateApps con la chiave stessa.
È possibile che i server host limitino la possibilità di modificare le impostazioni della configurazione computer negando i diritti di override, ad esempio impedendo che le chiavi di crittografia possano essere ridefinite nel file Web.config per un'applicazione.
Sicurezza delle connessioni a un'origine dati dei ruoli
Stringhe di connessione
Come già accennato, è importante proteggere la stringa di connessione utilizzata per accedere a SQL Server, ad Active Directory o a un'altra applicazione di origine dati. Per proteggere la connessione al server database, è opportuno crittografare le informazioni relative alla stringa di connessione incluse nella configurazione utilizzando la configurazione protetta. Per ulteriori informazioni, vedere Crittografia delle informazioni di configurazione utilizzando la configurazione protetta.
Connessione a SQL Server con la sicurezza integrata
Per eseguire la connessione a computer che eseguono SQL Server, si consiglia di utilizzare la sicurezza integrata per evitare che la stringa di connessione venga danneggiata e che l'ID utente e la password risultino visibili. Quando si specifica una connessione che utilizza la sicurezza integrata per connettersi a un computer che esegue SQL Server, la funzionalità di gestione dei ruoli viene reimpostata sull'identità del processo. Si consiglia di verificare che l'identità del processo che esegue ASP.NET, ad esempio il pool di applicazioni, sia l'account predefinito del processo o un account utente con diritti limitati. Per ulteriori informazioni, vedere Rappresentazione ASP.NET.
Autorizzazioni per il database di SQL Server
Il database di SQL Server in cui sono archiviate le informazioni sugli utenti relative ai ruoli include visualizzazioni e ruoli di database che consentono di limitare l'accesso degli utenti alle sole visualizzazioni e funzionalità necessarie. Si consiglia di assegnare privilegi minimi all'ID utente utilizzato per la connessione al database dei ruoli di SQL Server. Per ulteriori informazioni, vedere la classe Ruoli e viste nel database dei servizi dell'applicazione per SQL Server.
Identità del processo di lavoro di SQL Server Express
In SQL Server Express 2005 è disponibile una nuova modalità operativa che consente a SQL Server di avviare un processo di lavoro in esecuzione come identità dell'utente connesso. Questa funzionalità, definita modalità "esegui come utente", è indicata per sviluppare applicazioni desktop quando si utilizza IIS. Tuttavia non è opportuno avviare processi di lavoro in server Web contenenti più codebase cliente non attendibili. In questi casi la funzionalità "esegui come utente" deve essere disattivata in modo esplicito. Per disattivare la funzionalità, è possibile stabilire una connessione a un'istanza di SQL Express, ad esempio osql –E –S .\sqlexpress, quindi eseguire il comando Transact-SQL seguente.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Sicurezza dell'archivio autorizzazioni
Per aumentare la sicurezza dell'origine dati quando si utilizza l'oggetto AuthorizationStoreRoleProvider, è necessario memorizzare le informazioni sui ruoli in un server Active Directory e non in un archivio autorizzazioni basato su file. In questo modo il file di archiviazione dei criteri non potrà essere visualizzato se il server Web viene compromesso.
La funzionalità di gestione dei ruoli ripristina l'identità del processo durante la connessione a un server Active Directory. Si consiglia di verificare che l'identità del processo che esegue ASP.NET, ad esempio il pool di applicazioni, sia l'account predefinito del processo o un account utente con diritti limitati. Per ulteriori informazioni, vedere Rappresentazione ASP.NET. È inoltre necessario assegnare le autorizzazioni all'account nell'archivio autorizzazioni di Active Directory in modo da consentire l'accesso solo alla specifica applicazione di gestione delle autorizzazioni o all'ambito necessario per l'applicazione ASP.NET.
Per proteggere la connessione al server Active Directory, utilizzare un strumento di crittografia di rete, ad esempio IPSec (Internet Protocol Security, sicurezza protocollo Internet).
Sicurezza dei cookie dei ruoli
Per migliorare le prestazioni, è possibile specificare che i nomi dei ruoli per un utente vengano memorizzati nella cache di un cookie di sessione impostando l'attributo cacheRolesInCookie dell'elemento roleManager su true. Per impostazione predefinita, i nomi dei ruoli vengono archiviati in un formato crittografato. Per una maggiore sicurezza dei cookie dei ruoli, impostare l'attributo cookieRequireSSL su true e memorizzare i ruoli in un cookie sessione solo quando è attivato SSL (Secure Sockets Layer). In questo modo, i cookie dei ruoli non saranno visibili sulla rete né potranno essere utilizzati in un attacco di tipo replay nei confronti dell'applicazione.
Suggerimenti per impedire la condivisione dei cookie attraverso le applicazioni
Se l'attributo cacheRolesInCookie dell'elemento roleManager è impostato su true e l'attributo cookiePath è impostato su un percorso in cui sono incluse più applicazioni, a queste ultime verrà inviato lo stesso cookie dei ruoli. È possibile condividere il cookie dei ruoli tra più applicazioni specificando nell'elemento di configurazione machineKey le stesse informazioni sulla crittografia per ogni applicazione.
Per evitare di condividere i cookie contenenti i nomi dei ruoli attraverso più applicazioni, specificare nell'elemento di configurazione machineKey chiavi di crittografia separate per ogni applicazione, impostare l'attributo cookiePath per ogni applicazione sul percorso specifico dell'applicazione stessa e la proprietà ApplicationName su un valore unico per ogni applicazione.
Protezione delle pagine Web che utilizzano i ruoli
Le pagine applicazione che utilizzano dati riservati, ad esempio le pagine di accesso, devono essere protette tramite i meccanismi di sicurezza Web standard, ad esempio utilizzando SSL e specificando che gli utenti, per eseguire operazioni critiche quali l'aggiornamento delle informazioni utente o l'eliminazione degli utenti, devono aver effettuato l'accesso.
Inoltre, le pagine non devono esporre in testo non crittografato i dati riservati, ad esempio le password e, in alcuni casi, i nomi utente. Assicurarsi che le pagine che visualizzano tali informazioni utilizzino la sicurezza SSL e siano disponibili solo per gli utenti autenticati. Evitare inoltre che i dati riservati siano archiviati in cookie o inviati attraverso connessioni non sicure.
Protezione contro gli attacchi Denial of Service
È possibile che i metodi che eseguono aggiornamenti o operazioni di ricerca estese riducano la capacità di risposta dell'origine dati dei ruoli quando questa viene chiamata contemporaneamente da più client. Per ridurre i rischi di un attacco Denial of Service, limitare l'accesso alle pagine ASP.NET in cui sono implementati metodi di ricerca o aggiornamento del database ai soli utenti con privilegi di amministratore ed esporre solamente le pagine ASP.NET che forniscono la convalida dell'appartenenza ai ruoli per l'utilizzo generale.
Messaggi di errore ed eventi
Eccezioni
Per impedire che le informazioni riservate risultino visibili a origini indesiderate, configurare l'applicazione in modo che i messaggi di errore dettagliati non vengano visualizzati o che vengano visualizzati solo quando il client è il server Web stesso. Per ulteriori informazioni, vedere Elemento customErrors (schema delle impostazioni ASP.NET).
Log eventi
Se il server esegue Windows Server 2003, è possibile migliorare la sicurezza dell'applicazione impostando la sicurezza del log eventi e definendo i parametri relativi alla dimensione, al mantenimento e ad altre proprietà del log per impedire un attacco di tipo Denial of Service.
Informazioni di analisi
È possibile configurare il server Web in modo che esegua l'analisi di alcune azioni relative alla funzionalità di gestione dei ruoli e memorizzi le informazioni di analisi in un file log. Poiché nel file log dell'analisi possono essere memorizzate anche informazioni riservate, ad esempio i nomi utente o i nomi dei ruoli, è necessario che la possibilità di attivare la funzionalità di analisi, nonché di configurare la posizione del file log di analisi e di accedervi, sia limitata ai soli amministratori.
Provider di ruoli personalizzati
Quando si crea un provider di ruoli personalizzato, assicurarsi di seguire le procedure di sicurezza ottimali per evitare attacchi, ad esempio attacchi di tipo SQL injection, durante l'utilizzo di un database. Quando si utilizza un provider di ruoli personalizzato, verificare che per tale provider siano state implementate le procedure ottimali di sicurezza.
Utilizzo di caratteri dipendenti dalle impostazioni cultura
Quando si utilizza il provider di ruoli SQL Server o un provider di ruoli personalizzato, l'origine dati potrebbe essere configurata per l'archiviazione dei dati dei ruoli in un formato dipendente dalle impostazioni cultura. Tuttavia, ASP.NET valuta sempre i nomi dei ruoli specificati nell'elemento di configurazione dell'autorizzazione e i nomi dei ruoli nell'origine dati come elementi con impostazioni cultura invarianti. Ne consegue che agli utenti non autorizzati potrebbero essere concesse autorizzazioni indesiderate perché quando il relativo nome di ruolo non autorizzato viene considerato come elemento con impostazioni cultura invarianti è uguale al nome di un ruolo autorizzato. Per evitare che gli utenti dispongano di accesso non autorizzato, assicurarsi che i nomi dei ruoli siano univoci se vengono valutati come elementi con impostazioni cultura invarianti.