Linee guida

In generale le linee di condotta da seguire sono le seguenti:

• non eseguire MAI l'applicazione con l'identità di System Administrator;
• eseguire l'applicazione con l'utente che abbia i minori privilegi possibili;
• definire i permessi di tutte le risorse richieste dalla propria applicazione usando le impostazioni più restrittive, ad esempio assegnando a tutti i file solo l'autorizzazione per la lettura (salvo quelli che si prevede di modificare durante l'esecuzione, come i file di database);
• mantenere i file dell'applicazione all'interno della cartella root del sito web, impedendo agli utenti di poter specificare o selezionare percorsi esterni all'applicazione (ad esempio, utilizzando sempre e solo Server.MapPath per la costruzione di percorsi fisici su disco);
• non elevare mai il tipo di utente associato al processo di IIS (il valore predefinito in II6 è Network Service) a meno che non sia strettamente necessario (ad esempio, per l'esecuzione di CGI).

Per maggiori informazioni su come configurare l'identità dei processi di IIS si veda la documentazione su MSDN relativa alla configurazione delle identità del worker process e alla configurazione dell'identità del pool di applicazioni in IIS 6.0.

Altri accorgimenti per la sicurezza delle applicazioni Web

Oltre a quanto già detto nei paragrafi precedenti e nalla prima parte dell'articolo in merito ad attacchi di tipo specifico, è opportuno adottare i seguenti accorgimenti generali per garantire la sicurezza di un'applicazione Web:

• eseguire frequenti backup e conservarli in un luogo sicuro;
• garantire la sicurezza fisica della sala dati che ospita i server affidandosi a fornitori attendibili e certificati;
• proteggere il server e l'eventuale rete interna adottando tutte le misure possibili: firewall hardware e/o software, controllo antivirus, aggiornamenti dei sistemi operativi e dei software installati, chiusura delle porte TCP/UDP non utilizzate, protezione di IIS, arresto dei servizi non necessari, verifica del traffico in ingresso e in uscita, verifica del log degli eventi di Windows, utilizzo di file system NTFS (non FAT32, meno sicuro);
• evitare di memorizzare dati riservati in locazioni accessibili ai client (ad esempio, non salvare mai le password in campi nascosti o cookie). Spesso vengono usati proprio i campi nascosti (<input type="hidden" ... />) per conservare lo stato della pagina tra un postback e l'altro, ma, dato che la modifica dei valori memorizzati in campi nascosti (tecnica nota come tampering) è molto semplice, è ncessario crittarli prima di inviarli al client e quindi decodificarli (gestendo eventuali errori tramite try...catch...) prima di utlizzarli lato server;
• considerare l'utilizzo di SSL (Secure Sockets Layer) qualora sia necessario uno scambio di informazioni riservate tra client e server, utilizzando certificati validi rilasciati da un'authority attendibile;
• proteggere le informazioni di configurazione riservate utilizzando la configurazione protetta come illustrato precedentemente;
• utilizzare algoritmi di crittazione avanzati (namespace System.Security.Cryptography) evitando l'adozione di soluzioni improvvisate;
• adottare tutte le misure necessarie e possibili per impedire attacchi di tipo "denial of service" (che consistono nel saturare un'applicazione fino a renderla non disponibile):
  a) rilasciare sempre le risorse, anche in caso d'errore utilizzando un blocco" try...finally..." o mediante lo statement "using" per le risorse che implementano l'interfaccia IDisposable;
  b) limitare la CPU disponibile per ogni applicazione Web;
  c) limitare ad un numero ragionevole i risultati di una query sul database, eventualmente paginando i risultati;
  d) limitare l'input degli utenti mediante il parametro maxRequestLength;
  e) verificare tutti gli input degli utenti (consistenza e dimensione) prima di utilizzarli;
• se l'applicazione prevede l'upload di file, analizzare oltre all'estensione, anche il content-type dei file inseriti;
• creare messaggi d'errore sicuri, impedendo che da essi un utente malintenzionato possa ricavare informazioni utili per organizzare un attacco, come nome utente, password, informazioni relative all'accesso o alla struttura della base dati e percorsi sul filesystem relativi o assoluti. In generale è buona norma evitare di mostrare ogni tipo di dettaglio sull'errore che si è verificato; per consentire il debug dell'applicazione, è consigliabile utilizzare un sistema di logging specifico (registro degli eventi di Windows, log su file, ecc.) oppure mostrare i dettagli delle eccezioni esclusivamente agli utenti connessi localmente al server Web o forniti di credenziali specifiche. Maggiori informazioni sulla creazione di messaggi di errore protetti sono disponibili su MSDN;
• vigilare su eventuali tentativi ripetuti di accesso al sistema o su richieste eccessive pervenute al server Web.

Risorse utili e approfondimenti

• Il sito Web di Microsoft Patterns&Practices (in lingua inglese) presenta importanti informazioni sulla protezione e la sicurezza delle applicazioni ASP.NET, in particolare si segnalano i seguenti contenuti: a) la guida Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (disponibile anche il download in formato PDF), una raccolta completa (oltre 600 pagine) di linee guida per lo sviluppo e la costruzione di applicazioni ASP.NET sicure; le informazioni sono riferite ad ASP.NET 1.1, ma restano essenzialmente valide anche per le versioni successive; b) alla pagina Security How Tos Index è possible consultare l'elenco completo dei suggerimenti in materia di sicurezza pubblicati dal team di Patterns&Practices di Microsoft, ordinati per argomento (ASP.NET 1.1, ASP.NET 2.0, autenticazione e autorizzazione, ecc.) o alfabeticamente; c) una serie di checklist da stampare per verificare in modo puntuale che le nostre applicazioni siano sviluppate e distribuite rispettando le principali regole di sicurezza; d) lo strumento Guidance Explorer raccoglie una serie indicazioni e suggerimenti per creare applicazioni sicure e performanti.
  
  
• Security Developer Center è la sezione di MSDN dedicata alla sicurezza con articoli, esempi di codice e strumenti per rendere sicure le nostre applicazioni .NET.
  
  
• Il sito Web dedicato a IIS7 (www.iis.net) fornisce informazioni utili sul nuovo Web Server di Microsoft; in particolare, per quanto riguarda le migliorie apportate in chiave sicurezza rispetto alle versioni precedenti, si rimanda all'articolo (in lingua inglese) Changes between IIS6 and IIS7 Security.
  
  
• I blog ACE Team e hackers@microsoft raccolgono informazioni e consigli in materia di sicurezza.

Conclusioni

I tentativi di attacco sono sempre più frequenti e raffinati, per cui chi realizza applicazioni ASP.NET deve necessariamente porre estrema attenzione alla sicurezza in ogni fase dello sviluppo, dalla progettazione alla realizzazione, al testing, alla messa in produzione. In questo articolo sono state presentate le modalità di attacco più diffuse, gli errori più frequenti e gli accorgimenti da adottare per rendere sicure le nostre applicazioni.

La sicurezza delle applicazioni è però un argomento così vasto e complesso da non essere trattabile in modo esaustivo in un solo articolo; solo l'esperienza, l'attenzione e la curiosità di sviluppatori e professionisti IT possono contribuire a rendere realmente sicuri i nostri applicativi.

Ricordiamoci sempre che la sicurezza è - e deve essere - un requisito, non un aspetto o una funzionalità facoltativa.

Attenzione: Questo articolo contiene un allegato

Contenuti dell'articolo

• Pagina 1
  • Protezione da SQL Injection
  • Scenari a rischio
• Pagina 2
  • Protezione del database
  • Come scegliere la modalità di accesso a SQL Server
  • Come utilizzare la configurazione protetta
• Pagina 3
  • Applicare i privilegi minimi necessari
• Pagina 4
  • Altri accorgimenti per la sicurezza delle applicazioni Web
  • Risorse utili e approfondimenti
  • Conclusioni