Suggerimenti di base sulla protezione delle applicazioni Web
Aggiornamento: novembre 2007
Quello della creazione di un'applicazione Web sicura è un argomento lungo e complesso. In primo luogo, occorre uno studio che permetta di individuare i punti di vulnerabilità. È anche necessario familiarizzare con le funzionalità di sicurezza di Windows, .NET Framework e ASP.NET. Infine, è essenziale comprendere come utilizzare tali funzionalità per far fronte alle insidie.
Anche se non si è pratici di sicurezza, vi sono misure di base da prendere comunque per proteggere la propria applicazione Web. Nell'elenco riportato di seguito vengono fornite le istruzioni alle quali si consiglia di attenersi per garantire una sicurezza minima a tutte le applicazioni Web:
Suggerimenti generali per la sicurezza delle applicazioni Web
Eseguire le applicazioni con i minimi privilegi possibili
Conoscere gli utenti
Proteggersi dagli input utente dannosi
Accedere ai database secondo logiche di sicurezza
Creare messaggi di errore sicuri
Proteggere le informazioni riservate
Utilizzare i cookie secondo logiche di sicurezza
Proteggersi dagli attacchi denial of service
Nota: Per istruzioni complete e dettagliate sulla sicurezza da utilizzare per progettare, sviluppare, configurare e distribuire applicazioni Web ASP.NET più sicure, vedere i moduli di sicurezza disponibili nel sito Web Microsoft Patterns and Practices (informazioni in lingua inglese).
Suggerimenti generali per la sicurezza delle applicazioni Web
Anche la più elaborata sicurezza di un'applicazione può fallire se un utente malintenzionato è in grado di accedere ai computer con facilità. Attenersi alle seguenti indicazioni:
Eseguire frequentemente i backup e conservarli in un luogo fisicamente sicuro.
Collocare il computer server Web in un luogo fisicamente sicuro affinché utenti non autorizzati non possano accedervi, spegnerlo o rubarlo.
Utilizzare il file system Windows NTFS, non FAT32. NTFS offre una sicurezza di gran lunga superiore a quella offerta da FAT32. Per informazioni dettagliate, vedere la documentazione di Windows.
Proteggere il computer server Web e tutti i computer della stessa rete con password sicure.
Proteggere IIS. Per informazioni dettagliate, vedere il sito Web Microsoft TechNet Security Center (informazioni in lingua inglese).
Chiudere le porte non utilizzate e arrestare i servizi non utilizzati.
Eseguire un controllo antivirus che esegua il monitoraggio del traffico in ingresso e in uscita.
Definire e applicare criteri che impediscano agli utenti di conservare le password scritte in luoghi facilmente accessibili.
Utilizzare un firewall. Per ulteriori suggerimenti, vedere Microsoft Firewall Guidelines (informazioni in lingua inglese) nel sito Web Microsoft per la sicurezza.
Installare le ultime patch di sicurezza fornite da Microsoft e da altri fornitori. Nel sito Web Microsoft TechNet Security Center è ad esempio riportato un elenco degli articoli più recenti sulla sicurezza per tutti i prodotti Microsoft. Altri produttori dispongono di siti analoghi.
Utilizzare le funzionalità di log eventi di Windows ed esaminare frequentemente i log per individuare eventuali attività sospette. Tali attività includono tentativi ripetuti di effettuare l'accesso al sistema e un'impennata delle richieste pervenute al server Web.
Eseguire le applicazioni con i minimi privilegi possibili
Le applicazioni vengono eseguite all'interno di un contesto che dispone di privilegi specifici sul computer locale e, potenzialmente, sui computer remoti. Per informazioni sulla configurazione dell'identità delle applicazioni, vedere Configurazione dell'identità dei processi ASP.NET. Per effettuare l'esecuzione con privilegi minimi, attenersi alle seguenti indicazioni:
Non eseguire l'applicazione con l'identità di un utente di sistema (amministratore).
Eseguire l'applicazione nel contesto di un utente che dispone dei minimi privilegi possibili.
Negli elenchi di controllo di accesso (ACL, Access Control List) impostare le autorizzazioni su tutte le risorse necessarie per l'applicazione. Utilizzare la più restrittiva impostazione di autorizzazioni possibile. Se l'applicazione lo consente, impostare ad esempio i file come di sola lettura. Per un elenco della autorizzazioni ACL minime richieste per l'identità dell'applicazione ASP.NET, vedere Elenchi di controllo di accesso (ACL, Access Control List) ASP.NET necessari.
Tenere i file dell'applicazione Web in una sottocartella della cartella principale dell'applicazione. Non consentire agli utenti dell'applicazione di accedere ai file specificandone il percorso. In tal modo si riducono le probabilità che un utente riesca ad accedere alla cartella principale del server.
Conoscere gli utenti
In molte applicazioni gli utenti accedono al sito in modo anonimo, ovvero senza fornire credenziali. In tal caso, l'applicazione viene eseguita nel contesto di un utente predefinito e accede alle risorse di conseguenza. Per impostazione predefinita, tale contesto è quello dell'utente locale ASPNET (in Windows 2000 o Windows XP) o dell'utente NETWORK SERVICE (in Windows Server 2003) del computer server Web. Per limitare l'accesso agli utenti autenticati, attenersi alle seguenti indicazioni:
Se l'applicazione è un'applicazione Intranet, configurarla in modo che utilizzi la sicurezza integrata di Windows. In tal modo, le credenziali di accesso degli utenti potranno essere utilizzate per l'accesso alle risorse. Per ulteriori informazioni, vedere Rappresentazione ASP.NET.
Per acquisire le credenziali degli utenti, utilizzare una delle strategie di autenticazione previste da ASP.NET. Per un esempio, vedere Gestione di utenti tramite l'appartenenza.
Proteggersi dagli input utente dannosi
Come regola generale, non dare mai per scontato che l'input ricevuto da un utente sia sicuro. Gli utenti malintenzionati possono facilmente inviare informazioni potenzialmente dannose dal client all'applicazione. Per proteggersi da input dannosi, attenersi alle seguenti indicazioni:
Nelle pagine ASP.NET filtrare l'input degli utenti per individuarvi eventuali tag HTML che potrebbero contenere script. Per informazioni dettagliate, vedere Procedura: proteggere da attacchi tramite script in un'applicazione Web applicando alle stringhe la codifica HTML.
Non visualizzare mai input utente non filtrato. Prima di visualizzare informazioni non attendibili, codificare l'HTML per convertire in semplici stringhe gli script potenzialmente dannosi.
Non memorizzare mai input utente non filtrato in un database.
Se si desidera accettare tag HTML da un utente, filtrare l'input manualmente. Nel filtro definire esplicitamente cosa verrà accettato. Non creare un filtro che tenta di rimuovere gli input dannosi. È molto difficile prevedere tutti i possibili input dannosi.
Non supporre che le informazioni ricevute nell'intestazione di richiesta HTTP (nell'oggetto HttpRequest) siano sicure. Usare cautela con le stringhe di query, i cookie e così via. Nel caso abbiano particolare rilevanza per l'applicazione, si tenga conto del fatto che le informazioni riportate dal browser al server (informazioni di agente utente) sono soggette a spoofing.
Se possibile, non memorizzare informazioni riservate in un luogo accessibile al browser, come i campi nascosti o i cookie. Ad esempio, non memorizzare una password in un cookie.
Nota: Lo stato di visualizzazione viene memorizzato in un campo nascosto in forma codificata. Per impostazione predefinita, lo stato di visualizzazione include un codice di autenticazione messaggi (MAC, Message Authentication Code) che consente alla pagina di verificare che non sia stato alterato. Se nello stato di visualizzazione vengono memorizzate informazioni riservate, eseguire la crittografia impostando la proprietà ViewStateEncryptionMode della pagina su true.
Accedere ai database secondo logiche di sicurezza
I database dispongono solitamente di un proprio sistema di sicurezza. Un'importante aspetto della sicurezza di un'applicazione Web consiste nella corretta progettazione del modo in cui l'applicazione accederà al database. Attenersi alle seguenti indicazioni:
Utilizzare la sicurezza intrinseca del database per definire chi può accedere alle risorse del database. La strategia esatta dipende dall'applicazione e dal database utilizzati.
Se l'applicazione lo consente, impostare la sicurezza integrata così che solo gli utenti autenticati da Windows possano accedere al database. La sicurezza integrata è più sicura del passaggio di credenziali esplicite al database.
Se nell'applicazione viene utilizzato un accesso anonimo, creare un utente singolo con autorizzazioni estremamente limitate ed effettuare le query eseguendo il collegamento con le credenziali di tale utente.
Non creare istruzioni SQL concatenando stringhe contenenti input utente. Creare invece query con parametri e utilizzare l'input utente per impostare i valori dei parametri.
Per memorizzare un nome utente e una password da utilizzare come credenziali di accesso al database, utilizzare il file Web.config e proteggere tale file mediante la configurazione protetta. Per informazioni dettagliate, vedere Crittografia delle informazioni di configurazione utilizzando la configurazione protetta.
Per ulteriori informazioni sull'accesso ai dati in modo sicuro, vedere Protezione dell'accesso ai dati e Protezione di applicazioni ADO.NET.
Creare messaggi di errore sicuri
Se non si presta la dovuta attenzione, un utente malintenzionato potrebbe ricavare importanti informazioni dai messaggi di errore visualizzati dall'applicazione. Attenersi alle seguenti indicazioni:
Non scrivere messaggi di errore che visualizzano informazioni, come un nome utente, che potrebbero essere utilizzate da utente malintenzionati.
Configurare l'applicazione in modo che non visualizzi messaggi di errore dettagliati agli utenti. Se si desidera visualizzare messaggi di errore dettagliati per il debug, verificare prima se l'utente connesso è un utente locale del server Web. Per informazioni dettagliate, vedere Procedura: visualizzare messaggi di errore protetti.
Utilizzare l'elemento di configurazione customErrors per controllare la visualizzazione da parte di estranei delle eccezioni dal server.
Per le situazioni facilmente soggette ad errori, come gli accessi al database, creare soluzioni di gestione degli errori personalizzate. Per ulteriori informazioni, vedere Gestione degli errori nelle pagine e nelle applicazioni ASP.NET.
Proteggere le informazioni riservate
Per informazioni riservate si intende qualsiasi informazione da tenere segreta. Una tipica informazione riservata è una password o una chiave di crittografia. Se un utente non autorizzato entra in possesso delle informazioni riservate, i dati coperti dal segreto saranno compromessi. Attenersi alle seguenti indicazioni:
Se l'applicazione trasmette informazioni riservate tra il browser e il server, si consideri l'utilizzo di Secure Sockets Layer (SSL). Per informazioni dettagliate su come proteggere un sito mediante SSL, vedere l'articolo Q307267, "HOW TO: Secure XML Web Services with Secure Socket Layer in Windows 2000" nella Microsoft Knowledge Base all'indirizzo https://support.microsoft.com (informazioni in lingua inglese).
Utilizzare la configurazione protetta per proteggere le informazioni riservate in file di configurazione, come il file Web.config o Machine.config. Per ulteriori informazioni, vedere Crittografia delle informazioni di configurazione utilizzando la configurazione protetta.
Se si rende necessario memorizzare informazioni riservate, non farlo in una pagina Web, nemmeno in una forma ritenuta non visualizzabile agli utenti, ad esempio in codice server.
Utilizzare gli algoritmi di crittografia avanzata forniti nello spazio dei nomi System.Security.Cryptography.
Utilizzare i cookie secondo logiche di sicurezza
L'utilizzo dei cookie consente di memorizzare in modo semplice e pratico informazioni relative all'utente. Poiché vengono inviati al computer del browser, sono però esposti allo spoofing o ad altri impieghi dannosi. Attenersi alle seguenti indicazioni:
Non memorizzare informazioni riservate nei cookie. Non memorizzare ad esempio la password di un utente in un cookie, neanche temporaneamente. Come regola generale, non memorizzare in un cookie nulla che, in caso di spoofing, possa compromettere il funzionamento dell'applicazione. Memorizzare invece nel cookie un riferimento alla posizione sul server in cui è memorizzata l'informazione.
Impostare le date di scadenza dei cookie quanto più prossime possibile. Se è possibile, evitare l'uso di cookie permanenti.
Si consideri la possibilità di crittografare le informazioni contenute nei cookie.
Si consideri la possibilità di impostare le proprietà Secure e HttpOnly nel cookie su true.
Proteggersi dagli attacchi denial of service
Un modo indiretto di compromettere un'applicazione consiste nel renderla non più disponibile. Un utente malintenzionato può impegnare l'applicazione fino al punto di impedire che serva altri utenti oppure può provocarne l'arresto anomalo. Attenersi alle seguenti indicazioni:
Utilizzare la gestione degli errori, ad esempio il costrutto try-catch. Includere un blocco finally in cui si rilasciano le risorse in caso di errore.
Configurare IIS in modo che limiti i processi, al fine di impedire che un'applicazione utilizzi la CPU in modo sproporzionato.
Verificare che l'input utente rispetti i limiti di dimensioni prima di utilizzarlo o memorizzarlo.
Impostare protezioni sulla dimensione delle query al database. Prima di visualizzare i risultati di una query in una pagina Web ASP.NET, controllare ad esempio che questi non includano un numero di record irragionevole.
Porre un limite di dimensioni al caricamento di file, nel caso questo sia previsto dall'applicazione. È possibile impostare un limite nel file Web.config utilizzando una sintassi simile a quella riportata di seguito, in cui il valore maxRequestLength è espresso in KB:
<configuration> <system.web> <httpRuntime maxRequestLength="4096" /> </system.web> </configuration>
È inoltre possibile utilizzare la proprietà RequestLengthDiskThreshold per ridurre il sovraccarico della memoria determinato dagli upload di grandi dimensioni e dagli invii dei form.
Vedere anche
Concetti
Cenni preliminari sui pericoli di protezione a cui sono esposte le applicazioni Web