Protezione dell'appartenenza
Aggiornamento: novembre 2007
Il sistema di appartenenze ASP.NET fornisce funzionalità per la gestione e l'autenticazione degli utenti ed è solitamente utilizzato con l'autenticazione basata su form e i controlli di autenticazione, ad esempio Login, LoginView, LoginStatus, LoginName, PasswordRecovery e CreateUserWizard. In questo argomento viene descritto come migliorare la sicurezza della funzionalità di appartenenza avvalendosi delle procedure ottimali per la configurazione di un sito Web e per la scrittura di codice relativo alle classi di appartenenza.
L'adozione delle procedure ottimali 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 o altre origini dati delle appartenenze.
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 dell'appartenenza
Per le applicazioni ASP.NET la funzionalità di appartenenza è attivata per impostazione predefinita e non può essere disattivata. Nelle impostazioni di configurazione predefinite sono specificati i valori più sicuri. Per informazioni sulle impostazioni di configurazione dell'appartenenza e sui relativi valori predefiniti, vedere Elemento membership (schema delle impostazioni ASP.NET). Impostare l'attributo requiresQuestionAndAnswer su true, in particolare se è probabile che enablePasswordReset o enablePasswordRetrieval sia true.
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
Si consiglia di crittografare le password utente nell'origine dati delle appartenenze impostando un attributo passwordFormat su Hashed o Encrypted, dove Hashed corrisponde al formato più sicuro. 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 configurare un server host in modo da impedire alle applicazioni di eseguire l'override delle impostazioni di configurazione, 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 delle appartenenze
Stringhe di connessione
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
Si consiglia di eseguire la connessione a computer che eseguono SQL Server utilizzando 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 appartenenza 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 alle appartenenze include visualizzazioni e ruoli di database che consentono di limitare l'accesso degli utenti alle sole visualizzazioni e funzionalità necessarie. Si consiglia di assegnare all'ID utente con cui viene eseguita la connessione al database delle appartenenze di SQL Server solamente i privilegi strettamente necessari. Per ulteriori informazioni, vedere 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ù basi di codici 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
Protezione delle pagine Web che utilizzano l'appartenenza
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.
Sicurezza 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 delle appartenenze 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 e la gestione delle password 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.
Monitoraggio dello stato
Sia i tentativi di accesso completati che quelli non riusciti vengono registrati tramite la funzionalità di monitoraggio dello stato ASP.NET. Nella configurazione predefinita i nomi utente e gli altri dati di diagnostica relativi ai tentativi di accesso non riusciti vengono registrati nel log eventi Applicazione. Accertarsi che l'accesso al log eventi sia ristretto, in modo che queste informazioni non vengano diffuse.
Provider di appartenenze personalizzati
Quando si crea un provider di appartenenze 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 appartenenze 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 appartenenze SQL Server o un provider di appartenenze personalizzato, l'origine dati potrebbe essere configurata per l'archiviazione dei dati delle appartenenze in un formato dipendente dalle impostazioni cultura. Tuttavia, ASP.NET valuta i nomi utente dell'elemento di configurazione dell'autorizzazione e i nomi utente dell'archivio dei dati di appartenenze come elementi con impostazioni cultura invarianti. Ne consegue che a un utente non autorizzato potrebbe essere concessa l'autorizzazione perché quando il nome utente viene considerato come elemento con impostazioni cultura invarianti è uguale al nome di un utente autorizzato.
Per evitare che gli utenti dispongano di accesso non autorizzato, assicurarsi che i nomi utente siano univoci se vengono valutati come elementi con impostazioni cultura invarianti. In alternativa, è possibile specificare solo nomi di ruolo per l'autorizzazione mediante l'elemento di configurazione dell'autorizzazione e quindi assicurarsi che i nomi di ruolo siano univoci quando valutati come elementi con impostazioni cultura invarianti. La specifica dell'autorizzazione utilizzando nomi di ruolo è spesso preferita, perché la creazione e la gestione di ruoli possono essere limitate come funzioni amministrative.