Protezione dell'applicazione ASP.NET e dei servizi Web

In questa pagina

	Argomenti del modulo
	Obiettivi
	Ambito di applicazione
	Utilizzo del modulo
	Metodologia
	Informazioni preliminari
	Descrizione dei file Machine.Config e Web.Config
	Linee guida per i file Machine.Config e Web.Config
	Livelli di attendibilità in ASP.NET
	Identità di processo per ASP.NET
	Rappresentazione
	Autenticazione
	Autorizzazione
	Stato sessione
	Stato di visualizzazione
	MachineKey
	Debug
	Tracciatura
	Gestione delle eccezioni
	Servizi remoti
	Servizi Web
	Risorse proibite
	Directory bin
	Registro eventi
	Accesso ai file
	ACL e autorizzazioni
	Registro di sistema
	Accesso ai dati
	Condivisioni UNC
	Risorse COM/DCOM
	Considerazioni su Denial of Service (Negazione del servizio)
	Considerazioni sulle Web farm
	Istantanea di un'applicazione ASP.NET protetta
	Riepilogo
	Risorse aggiuntive

Argomenti del modulo

Le applicazioni Web ASP.NET protette si basano su un'infrastruttura di reti, host e piattaforme caratterizzata da un livello di protezione ottimale. Se tali elementi sono realmente efficaci, l'utente malintenzionato tenterà di sfruttare le vulnerabilità delle applicazioni e dei servizi Web, che generalmente utilizzano la porta 80 per l'ascolto. Se l'applicazione Web non è configurata in modo efficace, gli utenti malintenzionati possono accedere al sistema e sfruttarne le risorse.

Tra i compiti dell'amministratore vi è appunto l'analisi della configurazione predefinita a livello del computer e delle configurazioni delle singole applicazioni allo scopo di identificare e rimuovere le eventuali impostazioni vulnerabili o non protette.

In questo modulo vengono descritte le novità di ASP.NET dal punto di vista dell'amministratore di sistema e le modalità di configurazione delle impostazioni di protezione per l'intero computer e le singole applicazioni. Viene inoltre presentata la metodologia per la protezione delle applicazioni e dei servizi Web ASP.NET, che completa la metodologia per la protezione della rete, del server per applicazioni, del server dei database e del server Web già proposta.

Inizio pagina

Obiettivi

Il modulo consente di:

Inizio pagina

Ambito di applicazione

Le informazioni contenute in questo modulo sono valide per i seguenti prodotti e tecnologie:

Inizio pagina

Utilizzo del modulo

Questo modulo verte sugli aspetti essenziali della protezione delle applicazioni ASP.NET. Per trarre il massimo vantaggio dal modulo:

Per informazioni correlate, consultare il modulo 20 "Hosting di più applicazioni ASP.NET", in cui viene descritto come isolare dalle risorse di sistema essenziali e le une dalle altre più applicazioni Web in esecuzione sullo stesso server. Per ulteriori informazioni sulla configurazione dei criteri di protezione dall'accesso di codice (Code Access Security, CAS) per applicazioni e servizi Web con attendibilità parziale, consultare il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET".

Inizio pagina

Metodologia

Per proteggere l'applicazione ASP.NET è necessario rafforzare il sistema operativo e la base di installazione .NET Framework, quindi applicare impostazioni di configurazione protette per ridurre il profilo di attacco dell'applicazione.

Ad esempio:

Inizio pagina

Informazioni preliminari

Di seguito vengono riportati informazioni e dettagli da prendere in considerazione prima di avviare il processo di protezione delle applicazioni e dei servizi Web.

Modello di processo ASP.NET

In Microsoft Windows 2000, Internet Information Services (IIS) 5.0 esegue la totalità delle applicazioni e dei servizi Web nel processo di lavoro ASP.NET (Aspnet_wp.exe). L'unità di isolamento è il dominio dell'applicazione e ogni directory virtuale dispone di un proprio dominio di applicazione. Le impostazioni di configurazione a livello di processo vengono gestite dall'elemento <processModel> del file Machine.config.

In Microsoft Windows Server 2003, i pool di applicazioni IIS 6.0 consentono di isolare le applicazioni mediante processi separati. Per ulteriori informazioni, consultare il modulo 20 "Hosting di più applicazioni ASP.NET".

Account ASP.NET

L'account ASPNET è un account locale con privilegi minimi creato quando si installa .NET Framework. Per impostazione predefinita esegue il processo di lavoro ASP.NET e il servizio Stato ASP.NET.

Se si sceglie di eseguire le applicazioni Web mediante un account personalizzato, configurare l'account con privilegi minimi. Così facendo si riducono i rischi derivanti dall'esecuzione di codice da parte di un utente malintenzionato in grado di sfruttare il contesto di protezione dell'applicazione. È inoltre necessario specificare le credenziali dell'account nell'elemento <processModel>. Non archiviare credenziali non crittografate: utilizzare lo strumento Aspnet_setreg.exe per archiviare credenziali crittografate nel Registro di sistema. All'account personalizzato è inoltre necessario concedere le autorizzazioni NTFS appropriate.

Aspnet_setreg.exe e gli attributi di processo, sessione e identità

Aspnet_setreg.exe consente di archiviare le credenziali e le stringhe di connessione nel Registro di sistema in formato crittografato. Con questo strumento è possibile crittografare i seguenti attributi:

Nell'esempio seguente viene mostrato l'elemento <processModel> con un account personalizzato prima e dopo l'esecuzione di Aspnet_setreg.exe per la protezione delle credenziali:

<!--Before-->
<processModel userName="CustomAccount" password="Str0ngPassword" />
<!--After-->
<processModel
 userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"
 password="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,password"/>

È possibile scegliere il punto del Registro di sistema in cui archiviare i dati crittografati, che deve tuttavia trovarsi nella struttura HKEY_LOCAL_MACHINE. Oltre a crittografare i dati con l'interfaccia DPAPI (API di protezione dei dati) e ad archiviarli nel Registro di sistema, lo strumento applica un elenco di controllo di accesso (ACL, Access Control List) protetto per limitare l'accesso alla chiave del Registro di sistema. L'elenco di controllo di accesso della chiave del Registro di sistema garantisce Full Control (Controllo completo) per System, Administrators e Creator Owner. Se si utilizza lo strumento per crittografare le credenziali per l'elemento <identity> o la stringa di connessione per l'elemento <sessionState>, è necessario concedere l'accesso in lettura all'account di processo ASP.NET.

Per ottenere lo strumento Aspnet_setreg.exe e per ulteriori informazioni, vedere l'articolo 329290 della Microsoft Knowledge Base "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (in inglese).

La rappresentazione non è l'impostazione predefinita

Per impostazione predefinita le applicazioni ASP.NET sono prive di funzioni di rappresentazione. L'accesso alle risorse viene quindi eseguito utilizzando l'identità del processo di lavoro ASP.NET. Come requisito minimo, è necessario concedere l'accesso in lettura per l'identità di processo alle risorse Windows che dovranno essere utilizzate dall'applicazione creando un elenco di controllo di accesso adeguatamente configurato.

L'attivazione della rappresentazione consente di rappresentare il chiamante originario, ossia l'identità autenticata IIS, oppure un'identità fissa specificata nell'elemento <identity>. Per ulteriori informazioni, vedere "Rappresentazione" più avanti in questo modulo.

In genere le applicazioni ASP.NET non utilizzano la rappresentazione perché può incidere negativamente sulla progettazione, l'implementazione e la scalabilità. Ad esempio, l'utilizzo della rappresentazione impedisce la definizione di un pool di connessione di livello medio efficace, limitando così la scalabilità dell'applicazione. La rappresentazione può rivelarsi utile in scenari specifici, ad esempio quando l'applicazione utilizza il contesto di protezione dell'account utente anonimo per l'accesso alle risorse. Si tratta di una tecnica molto diffusa, spesso utilizzata quando lo stesso server ospita più applicazioni. Per ulteriori informazioni, consultare il modulo 20 "Hosting di più applicazioni Web".

HttpForbiddenHandler, Urlscan e 404.dll

Per impedire l'accesso alle risorse riservate è possibile utilizzare varie tecniche. In ASP.NET è disponibile l'elemento HttpForbiddenHandler, al quale è possibile mappare i tipi di file ASP.NET di cui si desidera impedire lo scaricamento su HTTP. I mapping vengono applicati con l'elemento <httpHandlers>.

In IISLockdown.exe è disponibile la libreria 404.dll. Questo file consente di configurare i servizi IIS per mappare le estensioni file indesiderate sulla libreria 404.dll, in modo da visualizzare il messaggio "HTTP 404 – File not found" ("File non trovato") alla richiesta dei tipi di file corrispondenti.

Infine, è possibile utilizzare il filtro ISAPI URLScan per bloccare le richieste inerenti a tipi di file e programmi eseguibili riservati. Il filtro URLScan viene fornito con lo strumento IISLockdown, ma può essere ottenuto separatamente. Per ulteriori informazioni, vedere l'articolo 307608 della Microsoft Knowledge Base "INFO: Using URLScan on IIS" e "Procedura: Utilizzo di URLScan" nella sezione "Procedure" di questa guida.

Per ulteriori informazioni su IISLockdown e URLScan, consultare il modulo 16 "Protezione del server Web".

AppSettings

L'elemento <appSettings> del file Web.config consente l'archiviazione dei dati di configurazione, quali ad esempio le stringhe di connessione ai database o le credenziali di account dei servizi, da parte delle applicazioni. Il vantaggio più importante offerto da questo elemento agli sviluppatori è costituito dalla possibilità di centralizzare e standardizzare l'archiviazione e il recupero dei dati di configurazione. Inoltre, la definizione di un punto unico nel file Web.config facilita le funzioni di amministrazione e distribuzione.

I dati riservati, quali le credenziali e le stringhe di connessione, non devono essere archiviati in formato non crittografato nei file di configurazione. Si consiglia pertanto agli sviluppatori di utilizzare DPAPI per crittografare i dati segreti prima dell'archiviazione.

Per ulteriori informazioni su AppSettings, vedere il programma "AppSettings in ASP.NET" su MSDN® TV all'indirizzo http://msdn.microsoft.com/msdntv (in inglese).

Inizio pagina

Descrizione dei file Machine.Config e Web.Config

Le funzioni di gestione della configurazione disponibili in .NET Framework interessano una vasta gamma di impostazioni che consentono all'amministratore di gestire l'applicazione Web e il relativo ambiente. Tali impostazioni sono archiviate in vari file di configurazione XML. Alcuni file XML sono dedicati al controllo delle impostazioni a livello di computer, mentre altri controllano la configurazione specifica dell'applicazione.

I file di configurazione XML possono essere modificati con un editor di testo qualsiasi, ad esempio Blocco note, oppure con editor XML. Per i tag XML viene fatta distinzione tra maiuscole e minuscole, pertanto è necessario prestare attenzione al modo in cui vengono digitati.

Nalla Figura 19.1 vengono mostrati i file di configurazione utilizzati per configurare le applicazioni Web ASP.NET disponibili per l'amministratore.

Figura 19.1
File di configurazione ASP.NET

I file Machine.config e Web.config hanno in comune numerosi elementi XML e sezioni di configurazione. Machine.config viene utilizzato per applicare i criteri globali del computer a tutte le applicazioni .NET Framework eseguite sul computer locale. Per personalizzare le impostazioni delle singole applicazioni gli sviluppatori possono inoltre utilizzare file Web.config specifici.

Nota: i file eseguibili di Windows, quali le applicazioni WinForm, vengono configurati mediante i file di configurazione. I nomi di tali file derivano dal nome del file eseguible dell'applicazione, ad esempio App.exe.config, dove app è il nome dell'applicazione.

Le modifiche apportate ai file di configurazione vengono applicate in modo dinamico e generalmente non richiedono il riavvio del server o dei servizi. Fanno eccezione le modifiche apportate all'elemento <processModel> del file Machine.config, descritto più avanti in questo modulo.

Nella Tabella 19.1 vengono indicati i percorsi dei file di configurazione.

Tabella 19.1 Percorsi dei file di configurazione

Per ulteriori informazioni sui file di configurazione CAS delle applicazioni Web ASP.NET, consultare il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET".

Valutazione dei criteri gerarchici

Per un'amministrazione di tipo centralizzato è possibile applicare le impostazioni in Machine.config. Le impostazioni presenti nel file Machine.config definiscono i criteri a livello del computer e possono essere utilizzate anche per applicare la configurazione specifica di un'applicazione mediante gli elementi <location>. Gli sviluppatori possono fornire file di configurazione specifici per le applicazioni al fine di ignorare determinati aspetti dei criteri globali del computer. Per le applicazioni Web ASP.NET, un file Web.config è disponibile nella directory principale virtuale dell'applicazione e facoltativamente nelle sottodirectory della directory principale virtuale. Osservare la disposizione mostrata nella Figura 19.2.

Figura 19.2
Configurazione gerarchica

Nella Figura 19.2, l'applicazione Web AppRoot dispone di un file Web.config memorizzato nella directory principale virtuale. La sottodirectory SubDir1, che non è una directory virtuale, contiene a sua volta un file Web.config, applicato quando una richiesta HTTP indica l'indirizzo http://AppRoot/SubDir1. Se una richiesta indica SubDir2, una directory virtuale, tramite AppRoot, ad esempio http://Server/AppRoot/SubDir2, verranno applicate le impostazioni dei file Machine.config e Web.config contenuti nella directory AppRoot. Se invece una richiesta indica SubDir2 ignorando AppRoot, ad esempio http://Server/SubDir2, verranno applicate solo le impostazioni del file Machine.config.

In ogni caso, le impostazioni di base provengono dal file Machine.config. In seguito le impostazioni sostitutive e le aggiunte vengono lette dai file Web.config specifici.

Se lo stesso elemento di configurazione viene utilizzato nel file Machine.config e in uno o più file Web.config, l'impostazione del file con livello gerarchico inferiore prevarrà sulle impostazioni di livello più elevato. Le nuove impostazioni di configurazione non applicate a livello del computer possono essere applicate ai file Web.config; inoltre, determinati elementi sono in grado di cancellare le impostazioni del livello superiore mediante l'elemento <clear>.

Nella seguente tabella viene indicata l'origine delle impostazioni di configurazione combinate per una combinazione di richieste Web applicata alla Figura 19.2.

Tabella 19.2 Applicazione delle impostazioni di configurazione

<location>

L'elemento <location> viene utilizzato per tre scopi principali:

Il tag <location> può essere utilizzato nel file Machine.config o nel file Web.config. Con Machine.config, l'eventuale percorso specificato deve essere completo e includere il nome del sito Web e il nome della directory virtuale, nonché, facoltativamente, una sottodirectory e un nome file. Ad esempio:

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
  <system.web> 
   . . .	
  </system.web>
</location>

Nota: quando si utilizza il tag di percorso presente nel file Machine.config è necessario includere il nome del sito Web.

Con Web.config, il percorso è di tipo relativo e include la directory virtuale dell'applicazione. Ad esempio:

<location path="SubDirName/PageName.aspx" >
   <system.web>
   . . .	
   </system.web>
</location>

Applicazione delle impostazioni di configurazione a file specifici

Per applicare le impostazioni di configurazione a un file specifico si utilizza l'attributo path. Ad esempio, per applicare le regole di autorizzazione al file Pagename.aspx dal file Web.config, utilizzare l'elemento <location> seguente:

<location path="SubDirName/PageName.aspx" >
  <system.web>
    <authorization>
      <deny roles="hackers" />
    </authorization>        
    </system.web>
</location>

Applicazione di impostazioni di configurazione specifiche in Machine.config

Utilizzando istruzioni <location> che specificano i percorsi delle directory delle applicazioni è inoltre possibile attivare impostazioni di applicazioni specifiche in Machine.config. In questo modo si centralizzano le funzioni di amministrazione. Nel frammento di codice seguente, ad esempio, viene mostrato come applicare l'utilizzo dell'autenticazione Windows e impedire l'utilizzo della rappresentazione in una particolare applicazione.

<location path="Default Web Site/YourApp">
  <system.web>
    <authentication mode="Windows"/>
    <identity impersonate="false"/>
  </system.web>
</location>

Blocco delle impostazioni di configurazione

Per impedire che le singole applicazioni possano annullare la configurazione dei criteri a livello del computer, inserire le impostazioni in un elemento <location> nel file Machine.config e impostare l'attributo allowOverride="false".

Ad esempio, per applicare criteri globali di computer che non possano essere annullati al livello dell'applicazione, utilizzare l'elemento <location> seguente:

<location path="" allowOverride="false">
  <system.web>
    ... machine-wide defaults
  </system.web>
</location>

Lasciando vuoto l'attributo path, si indica che le impostazioni devono essere applicate al computer, mentre allowOverride="false" garantisce che le impostazioni del file Web.config non andranno a sostituirsi ai valori specificati. Il tentativo di aggiunta di nuovi elementi al file Web.config genererà un'eccezione, anche nel caso in cui gli elementi di Machine.config corrispondano agli elementi di Web.config.

Inizio pagina

Linee guida per i file Machine.Config e Web.Config

Le impostazioni del file Machine.config applicano i valori predefiniti a livello di computer per il server. Quando si desidera adottare una particolare configurazione per tutte le applicazioni del server, utilizzare l'attributo allowOverride="false" nell'elemento <location> come descritto in precedenza. Questa tecnica risulta particolarmente adeguata per gli scenari di hosting in cui è necessario applicare aspetti del criterio di protezione a tutte le applicazioni del server.

Per le impostazioni che possono essere configurate per singola applicazione, è buona norma disporre di un file Web.config specifico. Malgrado sia possibile configurare singole applicazioni dal file Machine.config utilizzando più elementi <location>, disporre di file Web.config distinti offre notevoli vantaggi per la distribuzione e consente di limitare le dimensioni dei file Machine.config.

L'elemento da prendere in considerazione è rappresentato dalle impostazioni che devono essere applicate dai criteri a livello di computer. La scelta dipende dallo scenario specifico in cui si opera. Di seguito vengono descritti alcuni scenari comuni.

<location path="" allowOverride="false">
  <system.web>
    <authentication mode="Windows"/>
  </system.web>
</location>

<location path="" allowOverride="false>
  <system.web>
    <trust level="Medium" />
  </system.web>
</location>

ACL e autorizzazioni

I file di configurazione contengono dati riservati, pertanto necessitano di elenchi ACL opportunamente configurati che ne limitino l'accesso.

Machine.config

Per impostazione predefinita il file Machine.config è configurato con l'elenco ACL seguente:

Administrators: Full Control
System: Full Control
Power Users: Modify	
Users: Read and Execute
LocalMachine\ASPNET (process identity): Read and Execute

Nota: su Windows Server 2003, agli account Servizio locale (Local Service) e Servizio di rete (Network Service) viene garantito anche l'accesso in lettura.

Ai membri del gruppo Users viene garantito l'accesso in lettura per impostazione predefinita, dal momento che tutto il codice gestito eseguito sul computer deve essere in grado di leggere il contenuto del file Machine.config.

L'elenco ACL predefinito del file Machine.config è un valore predefinito protetto. Se tuttavia si dispone di una sola applicazione Web in esecuzione sul server oppure se tutte le applicazioni Web utilizzano la stessa identità di processo, è possible limitare ulteriormente l'ACL eliminando la voce di controllo dell'accesso utente (ACE). Quando si rimuove "users" dall'elenco DACL è necessario aggiungere in modo esplicito l'identità di processo Web.

Web.config

.NET Framework non installa alcun file Web.config. Se si installa un'applicazione che fornisce il proprio file Web.config, generalmente l'elenco ACL viene ereditato dalla directory inetpub, che per impostazione predefinita garantisce l'accesso in lettura ai membri del gruppo Everyone. Per bloccare il file Web.config specifico di un'applicazione, utilizzare gli elenchi ACL riportati di seguito.

Per .NET Framework versione 1.0:

Administrators: Full control
System: Full control
ASP.NET process identity: Read	
UNC Identity: Read
Impersonated Identity (Fixed Identity): Read
Impersonated Identity (Original Caller): Read

Per .NET Framework versione 1,1:

Administrators: Full control
System: Full control
ASP.NET process identity: Read
UNC Identity: Read
Impersonated Identity (Fixed Identity): Read 

Se le applicazioni utilizzano la rappresentazione di un account esplicito (se cioè rappresentano un'identità fissa), quale ad esempio <identity impersonate="true" username="WebUser" password="Y0urStr0ngPassw0rd$"/>, l'account (in questo caso WebUser) e il processo necessitano dell'accesso in lettura (Read).

Se la base del codice si trova in una condivisione UNC (Universal Naming Convention), è necessario garantire l'accesso in lettura all'identità di token UNC fornita da IIS.

Se la rappresentazione viene utilizzata ma non vengono utilizzate credenziali esplicite, come ad esempio nell'istruzione <identity impersonate="true"/> e nessuna convenzione UNC, in .NET Framework 1.1 dovrà essere garantito l'accesso solo al processo. Per .NET Framework 1.0 sarà necessario configurare anche l'elenco ACL per garantire l'accesso in lettura a qualsiasi identità che verrà rappresentata; in altre parole, dovrà essere garantito l'accesso in lettura al chiamante originario.

Inizio pagina

Livelli di attendibilità in ASP.NET

Il livello di attendibilità di un'applicazione determina le autorizzazioni garantite dai criteri CAS. Viene quindi stabilito in quale misura l'applicazione può accedere alle risorse protette ed eseguire operazioni che richiedono privilegi.

<trust>

Utilizzare l'elemento <trust> per configurare il livello di attendibilità dell'applicazione. Per impostazione predefinita il livello di configurazione è impostato su Full (Completo) come mostrato di seguito:

<!--  level="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>  

Questo frammento di codice indica che all'applicazione vengono garantite autorizzazioni CAS complete e senza limitazioni. Con questo tipo di configurazione la possibilità o l'impossibilità di accedere alle risorse da parte dell'applicazione dipende esclusivamente dalle impostazionidi protezione del sistem operativo.

Se si imposta il livello di attendibilità su un valore diverso da Full, è possibile suddividere le applicazioni Web ASP.NET esistenti a seconda dei tipi di risorse alle quali possono accedere e alle operazioni che sono in grado di eseguire. Si consiglia di provare le applicazioni con ciascuno dei livelli di attendibilità disponibili.

Per ulteriori informazioni sulla creazione di applicazioni Web con attendibilità parziale che utilizzano la protezione CAS, consultare il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET." Per ulteriori informazioni sull'utilizzo dei livelli di attendibilità per fornire l'isolamento delle applicazioni, consultare il modulo 20 "Hosting di più applicazioni Web".

Inizio pagina

Identità di processo per ASP.NET

Le applicazioni e i servizi Web ASP.NET vengono eseguiti in un'istanza condivisa del processo di lavoro ASP.NET (Aspnet_wp.exe). Le impostazioni a livello di processo, compresa l'identità di processo, vengono gestite tramite l'elemento <processModel> del file Machine.config.

<processModel>

L'identità del processo di lavoro ASP.NET viene configurata tramite l'impostazione degli attributi userName e password per l'elemento <processModel>. Nel configurare l'identità di processo, tenere presente quanto riportato di seguito:

Utilizzare l'account ASPNET predefinito

L'account ASPNET locale è l'account con privilegi minimi predefinito destinato in modo specifico all'esecuzione delle applicazioni e dei servizi Web ASP.NET. Se possibile, utilizzarlo servendosi della configurazione predefinita seguente:

<processModel enable="true" userName="machine" password="AutoGenerate" ... /> 

Utilizzare un account personalizzato con privilegi minimi

Se è necessario utilizzare un'identità alternativa per eseguire il processo di lavoro ASP.NET, accertarsi che l'account utilizzato sia configurato come account con privilegi minimi. In questo modo si limitano i danni che potrebbero essere causati da un utente malintenzionato in grado di eseguire il codice sfruttando il contesto di protezione del processo.

Si potrebbe decidere di utilizzare un account alternativo perché è necessario connettersi a un database Microsoft SQL Server™ remoto o a una risorsa di rete utilizzando l'autenticazione Windows. Tenere presente che per questo scopo è possibile utilizzare l'account ASPNET locale. Per ulteriori informazioni, vedere "Accesso ai dati" più avanti in questo modulo.

Per ulteriori informazioni sulle autorizzazioni NTFS richieste dall'account di processo ASP.NET, vedere "ACL e autorizzazioni" più avanti in questo modulo.

Agli account di processo ASP.NET è inoltre necessario concedere i diritti utente seguenti:

Crittografare le credenziali <processModel>

Se è necessario utilizzare un account personalizzato, non archiviare credenziali non crittografate in Machine.config: eseguire l'utilità Aspnet_setreg.exe per archiviare le credenziali crittografate nel Registro di sistema.

aspnet_setreg -k:Software\YourApp\process -u:CustomAccount :p:StrongPassword

<processModel
userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,password"/>

Per ulteriori informazioni, vedere l'articolo 329290 della Microsoft Knowledge Base "How To: Use the ASP.NET Utility to Encrypt Credentials and Sessione State Connection Strings" (in inglese).

Non eseguire ASP.NET con l'account SYSTEM

Non utilizzare l'account SYSTEM per eseguire ASP.NET e non concedere all'account di processo ASP.NET il diritto utente "Agisci come parte del sistema operativo". L'inosservanza di queste istruzioni annulla il principio di privilegio minimo e aumenta i danni che potrebbero essere causati da un utente malintenzionato in grado di eseguire codice sfruttando il contesto di protezione del processo dell'applicazione Web.

Inizio pagina

Rappresentazione

Per impostazione predefinita le applicazioni ASP.NET sono prive di funzioni di rappresentazione. Il contesto di protezione dell'account del processo di lavoro ASP.NET (ASPNET per impostazione predefinita) viene utilizzato quando l'applicazione accede alle risorse di Windows.

<identity>

L'elemento <identity> viene utilizzato per attivare la rappresentazione. È possibile rappresentare:

Rappresentazione del chiamante originario

Per rappresentare il chiamante originario, utilizzare la configurazione seguente:

<identity impersonate="true" />

La rappresentazione utilizza il token di accesso fornito da IIS che rappresenta il chiamante autenticato. Può trattarsi dell'account utente Internet anonimo, ad esempio, se l'applicazione utilizza l'autenticazione basata su form, oppure di un account Windows che rappresenta il chiamante originario se l'applicazione utilizza l'autenticazione Windows.

Se si rende possibile la rappresentazione del chiamante originario, tenere presente quanto riportato di seguito:

Per ulteriori informazioni, vedere "How To: Implement Kerberos Delegation for Windows 2000" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" all'indirizzo http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT05.asp (in inglese).

Rappresentazione di un'identità fissa

Per rappresentare un'identità fissa, specificarla tramite gli attributi userName e password per l'elemento <identity>:

<identity impersonate="true" userName="MyServiceAccount" 
                             password="Str0ng!Passw0rd"/>

Non archiviare le credenziali non crittografate come mostrato nell'esempio: utilizzare lo strumento Aspnet_setreg.exe per crittografare le credenziali e archiviarle nel Registro di sistema.

aspnet_setreg -k:Software\YourApp\identity -u:CustomAccount :p:StrongPassword

<identity impersonate="true"
userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

Per ulteriori informazioni, vedere l'articolo 329290 della Microsoft Knowledge Base "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" (in inglese).

Diritto utente Agisci come parte del sistema operativo

Quando si rappresenta un'identità fissa specificando gli attributi userName e password, l'account di processo di ASP.NET versione 1.0 richiede il diritto utente "Agisci come parte del sistema operativo" di Windows 2000. Poiché ciò innalza l'account di processo ASP.NET a un livello di privilegi simile a quello dell'account System locale, la rappresentazione di un'identità fissa con ASP.NET versione 1.0 è sconsigliata.

Nota: se si esegue ASP.NET versione 1.1 su Windows 2000 o Windows 2003 Server, questo diritto utente non è necessario.

Requisiti di autorizzazione NTFS

Per la rappresentazione delle identità è necessario configurare in modo adeguato le autorizzazioni NTFS. Per ulteriori informazioni, vedere "ACL e autorizzazioni" più avanti in questo modulo.

Inizio pagina

Autenticazione

L'elemento <authentication> consente di configurare la modalità di autenticazione utilizzata dall'applicazione.

<authentication>

La modalità di autenticazione appropriata dipende dal tipo di progettazione dell'applicazione o del servizio Web. L'impostazione Machine.config predefinita applica un valore predefinito di autenticazione Windows protetta, come mostrato di seguito.

<!-- authentication Attributes:
     mode="[Windows|Forms|Passport|None]" -->
<authentication mode="Windows" />

Linee guida per l'autenticazione basata su form

Per utilizzare l'autenticazione basata su form, impostare innanzi tutto mode="Forms" per l'elemento <authentication>. Quindi configurare l'autenticazione basata su form utilizzando l'elemento figlio <forms>. Nel frammento seguente viene mostrata la configurazione protetta dell'elemento di autenticazione <forms>:

<authentication mode="Forms"> 
  <forms loginUrl="Restricted\login.aspx"  Login page in an SSL protected folder
         protection="All"                  Privacy and integrity
         requireSSL="true"                 Prevents cookie being sent over http
         timeout="10"                      Limited session lifetime
         name="AppNameCookie"              Unique per-application name
         path="/FormsAuth"                    and path
         slidingExpiration="true" >        Sliding session lifetime
  </forms>
</authentication>

Per migliorare la protezione dell'autenticazione basata su form, seguire i consigli riportati di seguito:

Partizionare il sito Web

Separare le zone di accesso pubblico e limitato del sito Web. Collocare la pagina di accesso dell'applicazione nonché le pagine e le risorse alle quali dovrebbero accedere soltanto gli utenti dell'autenticazione in una cartella separata dalle zone di accesso pubblico. Proteggere le sottocartelle riservate configurandole in IIS per la richiesta dell'accesso SSL, quindi utilizzare gli elementi <authorization> per limitare l'accesso e provocare una procedura di accesso specifica. Ad esempio, la configurazione Web.config seguente consente a chiunque di accedere alla directory corrente (accesso pubblico), ma impedisce agli utenti non autenticati di accedere alla sottocartella riservata. Qualsiasi tentativo di accesso alla sottocartella provoca una procedura di accesso Forms.

<system.web>
  <!-- The virtual directory root folder contains general pages.
       Unauthenticated users can view them and they do not need 
       to be secured with SSL. -->
  <authorization>
    <allow users="*" />
  </authorization>
</system.web>

<!-- The restricted folder is for authenticated and SSL access only. -->
<location path="Restricted" >
  <system.web>
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</location>

Per ulteriori considerazioni di programmazione, ad esempio sulle modalità di spostamento tra le pagine ad accesso limitato e ad accesso libero, vedere "Autenticazione basata su form" nel modulo 10 "Creazione di pagine e controlli ASP.NET protetti."

Impostare protection="All"

Questa impostazione garantisce che il cookie dell'autenticazione basata su form venga crittografato per salvaguardare la privacy e l'integrità. Le chiavi e gli algoritmi utilizzati per la crittografia del cookie sono specificati nell'elemento <machineKey>.

I controlli della crittografia e dell'integrità impediscono la manomissione del cookie, ma non riducono il rischio di attacchi di tipo riproduzione del cookie nel caso in cui un utente malintenzionato riesca ad acquisire il cookie. Inoltre, utilizzare SSL per impedire che un utente malintenzionato possa acquisire il cookie utilizzando il software di monitoraggio della rete. I cookie possono essere rubati con attacchi di tipo XSS (Cross-site Scripting, Script tra siti) e ciò malgrado l'utilizzo di SSL. Per ridurre al minimo tale rischio, è opportuno dotare l'applicazione di una strategia di convalida dell'input appropriata.

Utilizzare valori di timeout piccoli per i cookie

Utilizzare valori di timeout piccoli per limitare la durata delle sessioni e ridurre le possibilità di attacchi di tipo riproduzione di cookie.

Valutare l'opportunità di utilizzare una scadenza prefissata

Valutare l'opportunità di impostare slidingExpiration="false" nell'elemento <forms> per stabilire la scadenza del cookie, anziché reimpostare la scadenza dopo ogni richiesta Web. Tale impostazione è importante se non si utilizza SSL per proteggere il cookie.

Nota: questa funzione è disponibile in .NET Framework versione 1.1.

Utilizzare SSL con l'autenticazione basata su form

Utilizzare SSL per proteggere le credenziali e il cookie di autenticazione. SSL impedisce agli utenti malintenzionati di acquisire le credenziali o il cookie di autenticazione basata su form utilizzato per identificare se stessi nei confronti dell'applicazione. Un cookie di autenticazione rubato equivale a un accesso rubato.

Impostare requireSSL="true". Ciò comporta l'impostazione dell'attributo Secure nel cookie, che garantisce che il cookie non venga trasmesso da un browser al server tramite un collegamento HTTP. È richiesto il protocollo HTTPS (SSL).

Nota: si tratta di un'impostazione di .NET Framework versione 1.1, che assume dati di programmazione esplicita per impostare l'attributo Secure del cookie nelle applicazioni create con la versione 1.0. Per ulteriori informazioni e codice di esempio, consultare il modulo 10 "Creazione di pagine e controlli ASP.NET protetti".

Se non si utilizza SSL, impostare slidingExpiration = "false"

Con l'impostazione di slidingExpiration su 'false' si definisce il periodo di timeout del cookie come numero di minuti trascorsi dalla prima creazione del cookie. Senza tale impostazione il timeout viene rinnovato a ogni richiesta inviata al server Web. L'acquisizione del cookie fornisce all'utente malintenzionato la quantità di tempo necessaria per accedere all'applicazione in qualità di utente autenticato.

Nota: questa funzione è disponibile in .NET Framework versione 1.1.

Non utilizzare l'elemento <credentials> sui server di produzione

La possibilità di archiviare le credenziali utente in file di configurazione XML viene fornita come supporto per le funzioni di sviluppo rapido e di test limitato. Non utilizzare le credenziali reali dell'utente finale. Le credenziali dell'utente finale non devono essere archiviate nei file di configurazione sui server di produzione. Le applicazioni di produzione dovrebbero implementare archivi di credenziali utente personalizzati, ad esempio, in un database di SQL Server.

Configurare l'elemento MachineKey

L'elemento <machineKey> definisce gli algoritmi utilizzati per crittografare il cookie dell'autenticazione basata su form. Questo elemento consente inoltre di gestire le chiavi di crittografia. Per ulteriori informazioni, vedere la sezione "MachineKey" più avanti in questo modulo.

Utilizzare nomi e percorsi univoci per i cookie

Utilizzare valori univoci per gli attributi name e path. Con l'impostazione di nomi univoci si evitano i problemi che possono verificarsi quando si ospitano più applicazioni sullo stesso server.

Inizio pagina

Autorizzazione

A meno che un utente non disponga di un'autorizzazione esplicita per accedere a una risorsa, ad esempio una pagina Web particolare, un file di risorsa, una directory e così via, la configurazione dovrebbe rifiutare l'accesso per impostazione predefinita. In ASP.NET sono disponibili due gatekeeper configurabili che possono essere utilizzati per controllare l'accesso alle risorse riservate. Sono:

Autorizzazione file

Questo gatekeeper può essere utilizzato soltanto dalle applicazioni che utilizzano l'autenticazione Windows e dispongono della configurazione seguente:

<authentication mode="Windows"/>

Il gatekeeper viene attivato automaticamente quando si utilizza l'autenticazione Windows e non richiede la rappresentazione. Per configurarlo, configurare gli ACL Windows su file e cartelle. Tenere presente che il gatekeeper controlla l'accesso ai soli tipi di file mappati da IIS all'estensione ISAPI ASP.NET Aspnet_isapi.dll.

Autorizzazione URL

Questo gatekeeper può essere utilizzato da qualsiasi applicazione. Per la configurazione si utilizzano elementi <authorization> che controllano gli utenti e i gruppi di utenti ai quali viene consentito l'accesso all'applicazione. Di seguito viene riportato l'elemento predefinito contenuto nel file Machine.config:

<authorization>
  <!-- allow/deny Attributes:
     users="[*|?|name]"
        * - All users
        ? - Anonymous users
        [name] - Named user
     roles="[name]" -->
 <allow users="*"/>
</authorization>

Note per il gatekeeper Autorizzazione URL

Utilizzare le istruzioni riportate di seguito per configurare in modo appropriato il gatekeeper Autorizzazione URL.

<location path="page.aspx" />
  <authorization>
    <allow users="DomainName\Bob, DomainName\Mary" />
    <deny users="*" />
  </authorization>
</location>

Inizio pagina

Stato sessione

Le applicazioni che si basano su uno stato sessione per singolo utente possono archiviare lo stato sessione negli elementi seguenti:

<sessionState>

L'indirizzo specifico e i dettagli di connessione sono memorizzati nell'elemento <sessionState> nel file Machine.config. Di seguito viene riportata l'impostazione predefinita:

<sessionState mode="InProc"
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10" sqlConnectionString="data 
              source=127.0.0.1;Integrated Security=SSPI" 
              cookieless="false" timeout="20"/>

Nota: se non si utilizza il servizio Stato ASP.NET sul server Web, utilizzare lo snap-in Servizi MMC per disattivarlo.

Protezione dell'archivio SQL Server per lo stato sessione

Se si utilizza un archivio SQL Server per lo stato sessione, seguire i consigli riportati di seguito per proteggere lo stato sessione.

Per ulteriori informazioni sull'impostazione del database di archiviazione SQL Server per lo stato sessione, vedere l'articolo 311209 della Microsoft Knowledge Base "How To: Configure ASP.NET for Persistent SQL Server Session State Management" (in inglese).

Utilizzare l'autenticazione Windows per il database

Se si utilizza mode="SQLServer", ricorrere all'autenticazione Windows per connettersi al database dello stato e utilizzare un account con privilegi minimi, quale ad esempio un account ASPNET locale duplicato. Così facendo si potrà utilizzare una connessione attendibile, la stringa di connessione non conterrà le credenziali e queste ultime non verranno passate tramite cavo al database.

Crittografare sqlConnectionString

Crittografare il valore dell'attributo sqlConnectionString con lo strumento Aspnet_setreg.exe. Tale operazione si rivela particolarmente importante se si utilizza l'autenticazione SQL per connettersi al database dello stato a causa della presenza delle credenziali nella stringa di connessione, ma è consigliata anche se si utilizza l'autenticazione Windows.

aspnet_setreg -k:Software\YourApp\sessionState -c:{your connection string}

<sessionState mode="SQLServer"
sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
\ASPNET_SETREG,sqlConnectionString" />

Limitare l'accesso dell'applicazione al database

È necessario limitare l'accesso dell'applicazione al database in modo che l'applicazione possa essere utilizzata esclusivamente per accedere alle necessarie tabelle di stato e alle stored procedure utilizzate da ASP.NET per l'esecuzione di query nel database.

sp_grantlogin 'MACHINE\ASPNETWebApps'

USE ASPState
GO
sp_grantdbaccess 'MACHINE\ASPNETWebApps', 'WebAppUser'

USE ASPState
GO
sp_addrole 'WebAppUserRole'

USE ASPState
GO
sp_addrolemember 'WebAppUserRole', 'WebAppUser'

grant execute on CreateTempTables to WebAppUserRole

Proteggere il canale

Per proteggere uno stato sessione riservato nella rete tra il server Web e l'archivio remoto dello stato, proteggere il canale di comunicazione tra i due server utilizzando IPSec o SSL. La privacy e l'integrità dei dati relativi allo stato della sessione verranno salvaguardati in tutta la rete. Se si utilizza SSL, sarà necessario installare un certificato server sul server del database. Per ulteriori informazioni sull'utilizzo di SSL con SQL Server, consultare il modulo 18 "Protezione del server database".

Protezione del servizio stato out-of-process

Se si utilizza mode=StateServer, seguire i consigli riportati di seguito per proteggere lo stato sessione:

Utilizzare un account con privilegi minimi per eseguire il servizio stato

Il servizio stato viene eseguito per impostazione predefinita mediante l'account locale con privilegi minimi ASPNET. Non dovrebbe essere necessario modificare tale configurazione.

Proteggere il canale

Se il servizio stato si trova su un server remoto, proteggere il canale di comunicazione con l'archivio remoto utilizzando IPSec per far sì che lo stato utente rimanga privato e inalterato.

Prendere in considerazione l'impostazione di un'altra porta predefinita

Per l'ascolto il servizio Stato ASP.NET utilizza la porta 42424. Per evitare di utilizzare questa porta predefinita e nota, impostarne un'altra modificando la chiave del Registro di sistema seguente:

HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters

Il numero della porta è definito dal valore con nome Port. Se si cambia il numero di porta nel Registro di sistema, impostando ad esempio 45678, sarà necessario modificare anche la stringa di connessione nell'elemento <sessionState> come indicato di seguito:

stateConnectionString="tcpip=127.0.0.1:45678"

Crittografare stateConnectionString

Crittografare il valore dell'attributo stateConnectionString per nascondere l'indirizzo IP e il numero di porta dell'archivio dello stato. Utilizzare lo strumento Aspnet_setreg.exe.

aspnet_setreg -k:Software\YourApp\sessionState -d:{your connection string}

<sessionState mode="StateServer"
sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
\ASPNET_SETREG,sqlConnectionString" ... />

Inizio pagina

Stato di visualizzazione

Se le applicazioni utilizzano lo stato di visualizzazione, accertarsi che sia protetto con codici di autenticazione dei messaggi (MAC) per fare sì che non venga modificato nel client. Utilizzando l'elemento <pages> nel file Machine.config è possibile attivare o disattivare lo stato di visualizzazione e la protezione MAC per tutte le applicazioni del computer.

<pages>

Per impostazione predefinita, l'attributo enableViewStateMac nell'elemento <pages> del file Machine.config garantisce la protezione dello stato di visualizzazione con un codice di autenticazione dei messaggi.

<pages buffer="true" enableSessionState="true"
       enableViewState="true" enableViewStateMac="true" 
       autoEventWireup="true" validateRequest="true"/>

Se si utilizza lo stato di visualizzazione, accertarsi che enableViewStateMac sia impostato su true. L'elemento <machineKey> definisce gli algoritmi utilizzati per proteggere lo stato di visualizzazione.

Inizio pagina

MachineKey

L'elemento <machineKey> consente di specificare le chiavi di crittografia, le chiavi di convalida e gli algoritmi utilizati per proteggere i cookie dell'autenticazione basata su form e lo stato di visualizzazione a livello di pagina. Nell'esempio di codice seguente viene presentata l'impostazione predefinita del file Machine.config:

<machineKey validationKey="AutoGenerate,IsolateApps" 
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

Nel configurare l'elemento <machineKey>, seguire i consigli riportati di seguito:

Utilizzare chiavi di crittografia univoche con più applicazioni

Se si ospitano più applicazioni su un solo server Web, è preferibile utilizzare chiavi univoche per ciascuna applicazione del computer piuttosto che una chiave singola per tutte le applicazioni. In questo modo si evita che un'applicazione possa ottenere lo stato di visualizzazione o cookie crittografati dell'autenticazione negli ambienti di hosting senza la necessaria autorizzazione.

Utilizzare anche l'impostazione IsolateApps. Si tratta di una nuova impostazione di .NET Framework versione 1.1 che induce ASP.NET a generare automaticamente le chiavi di crittografia e a renderle univoche per ogni applicazione.

Impostare validation="SHA1"

L'attributo validation specifica l'algoritmo utilizzato per il controllo dell'integrità dello stato di visualizzazione a livello di pagina. I valori possibili sono "SHA1", "MD5" e "3DES".

Se nell'elemento <forms> viene utilizzato protection="All", il cookie dell'autenticazione basata su form viene crittografato, operazione che a sua volta garantisce l'integrità. Indipendentemente dall'impostazione dell'attributo validation, l'autenticazione basata su Form utilizza TripleDES (3DES) per crittografare il cookie.

Nota: la crittografia del cookie dell'autenticazione basata su form è indipendente dall'impostazione validationkey e la chiave si basa sull'attributo decryptionKey.

Se nell'elemento <machineKey> viene impostato validation="SHA1", viene eseguito il controllo dell'integrità dello stato di visualizzazione a livello di pagina con l'algoritmo SHA1, presupponendo che l'elemento <pages> sia configurato per i codici MAC dello stato di visualizzazione. Per ulteriori informazioni, vedere "Stato di visualizzazione" nelle pagine precedenti di questo modulo.

È inoltre possibile impostare l'attributo di convalida su MD5. Si consiglia tuttavia di utilizzare SHA1 in quanto produce un hash più grande ed è quindi considerato più sicuro.

Se nell'elemento <machineKey> viene impostato validation="3DES", lo stato di visualizzazione a livello di pagina viene crittografato, operazione che fornisce anche il controllo dell'integrità, con l'algoritmo 3DES, anche se l'elemento <pages> è configurato per i codici MAC dello stato di visualizzazione.

Generare manualmente le chiavi per le Web farm

Nelle Web farm è necessario impostare valori di chiave espliciti e utilizzare gli stessi valori su tutti i computer membri. Vedere "Considerazioni sulle Web farm" più avanti in questo modulo.

Inizio pagina

Debug

L'elemento <compilation> controlla le impostazioni del compilatore utilizzate per la compilazione dinamica delle pagine avviata quando un client richiede una pagina Web (file .aspx file) o un servizio Web (file .asmx). Le build di debug non devono essere utilizzate sul server di produzione: le informazioni di debug rivestono una particolare importanza per i malintenzionati in quanto possono rivelare i dettagli del codice sorgente.

<compilation>

Questo elemento controlla il processo di compilazione. Accertarsi che le compilazioni di debug siano disattivate sui server di produzione. Impostare debug="false" come mostrato di seguito:

<compilation debug="false" explicit="true" defaultLanguage="vb" />

Per impostazione predefinita, i file temporanei vengono creati e compilati nella directory seguente:

%winnt%\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files

Utilizzando l'attributo tempDirectory è possibile specificare percorsi diversi per le singole applicazioni, anche se ciò non comporta vantaggi supplementari in termini di protezione.

Nota: L'identità di processo ASP.NET specificata nell'elemento <processModel> richiede diritti di accesso Full Control (Controllo completo) per la directory di compilazione temporanea.

Non archiviare i file di debug, con estensione .pdb, su un server di produzione insieme agli assembly.

Inizio pagina

Tracciatura

Si consiglia di disattivare la funzione di tracciatura sui server di produzione in quanto le informazioni di traccia a livello di sistema possono essere un valido aiuto per l'utente malintenzionato per definire l'applicazione e sondarne i punti deboli.

<trace>

La funzione di tracciatura viene configurata con l'elemento <trace>. Impostare enabled="false" sui server di produzione come segue:

<trace enabled="false" localOnly="true" pageOutput="false" 
       requestLimit="10" traceMode="SortByTime"/>

Se non è assolutamente necessario individuare i problemi in situazioni di utilizzo reale delle applicazioni, è preferibile simulare i problemi in un ambiente di test. In alternativa, è possibile attivare la tracciatura e impostare localOnly="true" per impedire che i dettagli della funzione vengano restituiti ai client remoti.

Inizio pagina

Gestione delle eccezioni

Fare in modo che i dettagli delle eccezioni non vengano trasmessi dalle applicazioni Web al client. Le informazioni di diagnostica a livello di sistema possono essere utilizzate per conoscere l'applicazione e sondarne i punti deboli da sfruttare in attacchi futuri.

<customErrors>

L'elemento <customErrors> consente di configurare messaggi di errore generici personalizzati da trasmettere al client quando si verifica una condizione di eccezione dell'applicazione. La pagina dell'errore dovrebbe includere un messaggio di errore adeguatamente generico e, facoltativamente, dettagli di supprto aggiuntivi. Questo elemento può essere utilizzato anche per restituire pagine di errore diverse a seconda della condizione di eccezione.

Verificare che l'attributo della modalità sia impostato su "On" e di aver specificato una pagina di reindirizzamento predefinita, come mostrato di seguito:

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

L'attributo defaultRedirect consente di utilizzare una pagina di errore personalizzata per l'applicazione, che potrebbe ad esempio includere informazioni dettagliate sui contatti di supporto.

Nota: non utilizzare mode="Off" in quanto provoca la trasmissione al client di pagine di errore dettagliate che contengono informazioni a livello di sistema.

Se si desidera vengano generate pagine di errore distinte per i vari tipi di errore, utilizzare uno o più elementi <error> come mostrato di seguito. In questo esempio gli errori di tipo "404 (non trovato)" vengono trasmessi a una pagina, gli errori di tipo "500 (errori interni del sistema)" vengono trasmessi a un'altra pagina e tutti gli altri errori vengono trasmessi alla pagina specificata nell'attrobuto defaultRedirect.

<customErrors mode="On" defaultRedirect="YourErrorPage.htm">
   <error statusCode="404" redirect="YourNotFoundPage.htm"/>
   <error statusCode="500" redirect="YourInternalErrorPage.htm"/>
</customErrors>

Inizio pagina

Servizi remoti

Non esporre gli endpoint dei servizi remoti .NET sui server Web Internet. Per disattivare i servizi remoti, disattivare le richieste relative alle estensioni .rem e .soap mappandole all'elemento HttpForbiddenHandler. Utilizzare gli elementi riportati di seguito dopo <httpHandlers>:

<httpHandlers>
  <add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
  <add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>
  . . .
</httpHandlers>

Nota: ciò non impedisce il collegamento di un'applicazione Web residente su un server Web a un oggetto downstream mediante l'infrastruttura dei servizi remoti. Viene tuttavia impedito ai client di connettersi agli oggetti residenti sul server Web.

Inizio pagina

Servizi Web

Configurare i servizi Web utilizzando l'elemento <webServices>. Per definire una configurazione protetta per i servizi Web:

Disattivare i servizi Web se non sono necessari

Se i servizi Web non vengono utilizzati, è preferibile disattivarli mappando le richieste dell'estensione file .asmx (servizio Web) a HttpForbiddenHandler nel file Machine.config,come indicato di seguito:

<httpHandlers>
  <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/>
  . . .
</httpHandlers>

Disattivare i protocolli inutilizzati

L'elemento <protocols> definisce i protocolli supportati dai servizi Web. Per impostazione predefinita, i protocolli HttpPost e HttpGet sono disattivati in .NET Framework versione 1.1:

<webServices>
  <protocols>
    <add name="HttpSoap1.2"/>
    <add name="HttpSoap"/>
    <!-- <add name="HttpPost"/> -->
    <!-- <add name="HttpGet"/> -->
    <add name="HttpPostLocalhost"/>
    <add name="Documentation"/>
  </protocols>
</webServices>

Disattivando i protocolli non necessari, compresi HttpPost e HttpGet, si riduce la superficie dell'area esposta agli attacchi. Ad esempio, un utente malintenzionato esterno può incorporare un collegamento dannoso in un messaggio di posta elettronica per eseguire un servizio Web interno utilizzando il contesto di protezione dell'utente finale. La disattivazione del protocollo HttpGet è una contromisura efficace. Da vari punti di vista, questo scenario è simile a un attacco di tipo XSS. Un variante di questo attacco utilizza un tag <img src="..." /> in una pagina Web con accesso pubblico per incorporare una chiamata GET in un servizio Web di una rete Intranet. Entrambi gli attacchi consentono a un utente esterno di richiamare un servizio Web interno. La disattivazione del protocollo HttpGetè una contromisura efficace.

Se il server di produzione fornisce servizi Web che possono essere rilevati pubblicamente, è necessario attivare HttpGet e HttpPost per far sì che i servizi possano essere rilevati con tali protocolli.

Disattivare la generazione automatica di WSDL

Il protocollo Documentation viene utilizzato per generare dinamicamente WSDL (Web Service Description Language). WSDL descrive le caratteristiche di un servizio Web, quali le relative firme dei metodi e i protocolli supportati. I client utilizzano queste informazioni per costruire messaggi formattati in modo appropriato. Per impostazione predefinita, i servizi Web espongono pubblicamente WSDL, rendendolo così disponibile a chiunque possa connettersi al server Web attraverso Internet.

IN alcuni casi, può essere utile distribuire manualmente i file WSDL ai partner e impedire l'accesso pubblico. Tramite questo approccio, il team di sviluppo è in grado di fornire singoli file .wsdl per ciascun servizio Web al team delle operazioni. Il team delle operazioni può quindi distribuirli ai partner specificati che desiderano utilizzare i servizi Web.

Per disattivare il protocollo Documentation, impostarlo come commento in Machine.config nel modo seguente:

<webServices>
  <protocols>
    <add name="HttpSoap"/>
    <!-- <add name="Documentation"/> -->
  </protocols>
</webServices>

Inizio pagina

Risorse proibite

Per impedire che risorse e file protetti vengano scaricati attraverso HTTP, mapparli su HttpForbiddenHandler di ASP.NET.

Mappare le risorse protette su HttpForbiddenHandler

I gestori HTTP si trovano in Machine.config sotto l'elemento <httpHandlers>. I gestori HTTP consentono l'elaborazione delle richieste Web relative a estensioni file specifiche. I servizi remoti non devono essere attivati sui server Web front-end; attivare i servizi remoti solo su server di applicazione di livello intermedio che sono isolati da Internet.

Per le risorse di .NET Framework, se non si utilizza un'estensione file mappare l'estensione su System.Web.HttpForbiddenHandler in Machine.config, come mostrato nell'esempio seguente:

<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />

In questo caso l'estensione file .vbproj è mappata su System.Web.HttpForbiddenHandler. Se un client richiede un percorso che termina ocn .vbproj, allora ASP.NET restituisce un messaggio indicante "This type of page is not served."

Inizio pagina

Directory bin

La directory bin sotto la directory principale virtuale di un'applicazione ASP.NET contiene gli assembly privati dell'applicazione, comprendenti le implementazioni a livello di classe di pagina dell'applicazione se i file di codice sottostante sono stati utilizzati durante lo sviluppo.

Proteggere la directory bin

Per proteggere la directory bin dell'applicazione e la logica aziendale contro download intenzionali:

Rimuovere le autorizzazioni Web

Utilizzare lo snap-in IIS e assicurarsi che la directory bin non disponga di autorizzazioni di esplorazione Lettura, Scrittura o Directory . Assicurarsi inoltre che le autorizzazioni Esecuzione non siano impostate su Nessuna.

Rimuovere tutte le impostazioni di autenticazione

Utilizzare lo snap-in per rimuovere le impostazioni di autenticazione dalla directory bin. Questo determina la negazione di tutti gli accessi.

Inizio pagina

Registro eventi

Gli account con privilegi minimi, come ASPNET, dispongono di autorizzazioni sufficienti per scrivere record nel registro eventi utilizzando le origini degli eventi esistenti. Tuttavia, essi non dispongono di autorizzazioni sufficienti per creare nuove origini di eventi. A tal scopo, è necessario inserire una nuova voce sotto la seguente chiave di registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Per evitare questo problema, è possibile creare origini di eventi al momento dell'installazione quando sono disponibili privilegi di amministratore. È possibile utilizzare una classe installer .NET, la cui istanza può essere creata da Windows Installer , se si utilizza lo sviluppo .msi, o dall'utilità di sistema InstallUtil.exe in caso contrario. Per ulteriori informazioni sull'utilizzo dei programmi di installazione del registro eventi, consultare il modulo 10 "Creazione di pagine e controlli ASP.NET protetti".

Se non è possibile creare origini di eventi al momento dell'installazione, è necessario aggiungere l'autorizzazione alla seguente chiave di registro e consentire l'accesso all'account di processo di ASP.NET o a qualsiasi account rappresentato se l'applicazione utilizza la rappresentazione.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

Come minimo, gli account devono disporre delle seguenti autorizzazioni:

Inizio pagina

Accesso ai file

Qualsiasi file a cui accede l'applicazione deve disporre di una voci di controllo dell'accesso (ACE) nell'elenco ACL che concede, come minimo, accesso in lettura all'account di processo di ASP.NET o all'identità rappresentata. Normalmente, gli elenchi ACL sono configurati nella directory e il file eredita l'impostazione.

Oltre a utilizzare autorizzazioni NTFS per limitare l'accesso ai file e alle directory, è anche possibile utilizzare livelli di attendibilità di ASP.NET per inserire vincoli nelle applicazioni e nei servizi Web per limitare le aree del file system a cui hanno accesso. Ad esempio, le applicazioni Web di media attendibilità possono accedere solo ai file all'interno della propria gerarchia di directory virtuale.

Per ulteriori informazioni sui criteri di protezione CAS di ASP.NET, leggere il modulo 9 "Utilizzo della protezione dall'accesso di codice con ASP.NET".

Inizio pagina

ACL e autorizzazioni

L'account di processo di ASP.NET e, per certe directory, qualsiasi identità di rappresentazione, se le applicazioni utilizzano la rappresentazione, richiede le seguenti autorizzazioni NTFS. Le autorizzazioni mostrate nella tabella 19.3 anno utilizzate in aggiunta a qualsiasi autorizzazione che potrebbe essere necessaria all'applicazione per accedere a risorse specifiche del file system.

Tabella 19.3 Autorizzazioni NTFS necessarie per gli account di processo di ASP.NET

Inizio pagina

Registro di sistema

Qualsiasi chiave di registro a cui accede l'applicazione deve disporre di una voci di controllo dell'accesso nell'elenco ACL che concede, come minimo, accesso in lettura all'account di processo di ASP.NET o all'identità rappresentata.

Inizio pagina

Accesso ai dati

Per accedere a un database remoto mediante l'autenticazione di Windows dall'applicazione ASP.NET, sono disponibili le seguenti opzioni:

Configurazione dell'accesso ai dati per l'applicazione ASP.NET

Qualunque sia l'approccio utilizzato, limitare l'account dell'applicazione nel database. A tal scopo, creare un accesso SQL Server per l'account al quale concedere l'accesso al database richiesto, quindi limitare le relative autorizzazioni in modo che possa accedere solamente al minimo necessario di oggetti del database. Idealmente, si dovrebbero limitare le autorizzazioni in modo che il nome di accesso possa accedere solamente alle stored procedure utilizzate dall'applicazione o dal servizio Web.

La seguente procedura presuppone che venga utilizzato un account locale in mirroring, ma lo stesso approccio può essere utilizzato con un account di dominio per limitare le funzionalità dell'account nel database.

sp_grantlogin 'MACHINE\ASPNETWebApp'

USE YourDatabase
GO
sp_grantdbaccess 'MACHINE\ASPNETWebApp', 'WebAppUser'

USE YourDatabase
GO
sp_addrole 'WebAppUserRole'

USE YourDatabase
GO
sp_addrolemember 'WebAppUserRole', 'WebAppUser'

grant execute on sprocname to WebAppUserRole

Inizio pagina

Condivisioni UNC

Sono disponibili due metodi principali attraverso i quali l'applicazione ASP.NET può utilizzare condivisioni UNC:

Accesso ai file su condivisioni UNC

Se l'applicazione accede ai file su una condivisione UNC, l'account di processo di ASP.NET o qualsiasi identità rappresentata deve disporre dei diritti di accesso appropriati definiti dall'elenco ACL sulla condivisione e sulla directory o file sottostante.

Se si utilizza l'account di processo locale di ASPNET, questo non dispone di un'identità di rete, quindi è necessario creare un account in mirroring sul server remoto con un nome utente e una password corrispondenti, oppure è necessario utilizzare un account di dominio con privilegi minimi che ha accesso a entrambi i server. In Windows Server 2003, l'account NetworkService che viene utilizzato per eseguire le applicazioni Web ASP.NET può essere autenticato attraverso la rete, quindi è sufficiente concedere i diritti di accesso all'account del computer.

Applicazioni host su condivisioni UNC

È possibile utilizzare IIS per configurare una directory virtuale che punti a una condivisione UNC situata su un altro computer, ad esempio, \\serverremoto\nomeapp. Procedendo in tal senso, IIS richiede di fornire credenziali di account, che vengono utilizzate per stabilire una connessione con il computer remoto.

Nota: le credenziali dell'account vengono memorizzate in formato crittografato nel metabase IIS ma sono disponibili attraverso una API. È necessario assicurarsi di utilizzare un account con privilegi minimi. Per ulteriori informazioni, vedere l'articolo della Microsoft Knowledge Base 280383, "IIS Security Recommendations When You Use a UNC Share and Username and Password Credentials" (in inglese).

Se l'applicazione risiede su una condivisione UNC, ASP.NET rappresenta il token UNC fornito da IIS (creato dalle credenziali dell'account fornite a IIS) per accedere a tale condivisione, a meno che non sia stata attivata la rappresentazione e sia stata utilizzata un'identità di rappresentazione fissa, come è mostrato nella seguente configurazione:

<identity impersonate="true"
  userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
  password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

Se è stato fornito un account di rappresentazione fissa attraverso gli attributi userName e password, ASP.NET lo utilizza in alternativa al token UNC di IIS per accedere alla condivisione. L'account di rappresentazione fisso viene utilizzato anche da qualsiasi accesso a risorse eseguito dall'applicazione.

Nota: nell'esempio precedente, è stato utilizzato Aspnet_setreg.exe per memorizzare le credenziali nel Registro di sistema.

Se si attiva la rappresentazione del chiamante originale (identità di IIS autenticata) mediante la seguente configurazione, ASP.NET utilizza ancora il token UNC per accedere ai file dell'applicazione sulla condivisione, sebbene qualsiasi accesso a risorse eseguito dall'applicazione utilizzi il token di rappresentazione.

<identity impersonate="true" />

Nota: anche l'account utilizzato per la condivisione UNC deve essere in grado di leggere Machine.config.

Considerazioni sulla protezione dall'accesso di codice

Alle applicazioni in una condivisione UNC viene concessa l'autorizzazione intranet impostata dai criteri di protezione dell'accesso di codice. L'autorizzazione intranet impostata non contiene AspNetHostingPermission, richiesta per l'esecuzione dalle applicazioni Web ASP.NET, così l'applicazione non verrà eseguita senza esplicite modifiche dei criteri di protezione.

Sono disponibili due opzioni:

Inizio pagina

Risorse COM/DCOM

L'applicazione utilizza l'identità di processo o di rappresentazione quando chiama risorse COM (ndash), come i componenti per servizi. L'autenticazione dal lato client e i livelli di rappresentazione vengono configurati mediante gli attributi di livello comAuthenticationLevel e comImpersonation nell'elemento <processModel> in Machine.config.

Per ulteriori informazioni e consigli, vedere "Considerazioni sui servizi Enterprise" nel modulo 17 "Protezione del server per applicazioni".

Inizio pagina

Considerazioni su Denial of Service (Negazione del servizio)

ASP.NET è dotato delle seguenti funzionalità per aiutare a contrastare attacchi denial of service rivolti a contro applicazioni ASP.NET:

<httpRuntime>

I valori di configurazione vengono mantenuti nell'elemento <httpRuntime> in Machine.config. Il seguente esempio di codice mostra le impostazioni predefinite di un Machine.config versione 1.1:

<httpRuntime executionTimeout="90" 
             maxRequestLength="4096" 
             useFullyQualifiedRedirectUrl="false" 
             minFreeThreads="8" 
             minLocalRequestFreeThreads="4" 
             appRequestQueueLimit="100" 
             enableVersionHeader="true"/>

È anche possibile ridurre l'attributo maxRequestLength per impedire che gli utenti carichino file molto grandi. Il valore massimo consentito è 4 MB. Nella competizione Open Hack, maxRequestLength era limitata a 0,5 MB come è mostrato nel seguente esempio:

<system.web>
   <!-- 1/2 MB Max POST length -->
   <httpRuntime maxRequestLength="512"/>
</system.web>

Nota: ASP.NET non gestisce gli attacchi a livello di pacchetto. Ciò può essere affrontato rafforzando lo stack TCP/IP. Per ulteriori informazioni sulla configurazione dello stack TCP/IP, vedere "Procedura: Rafforzamento delle protezioni dello stack TCP/IP" nella sezione "Procedura" di questa guida.

Inizio pagina

Considerazioni sulle Web farm

Se l'applicazione Web ASP.NET viene eseguita in una Web farm, allora non vi sono garanzie che le richieste successive da uno stesso client saranno servite dallo stesso server Web. Le implicazioni riguardano:

Stato sessione

Per evitare affinità di server, mantenere lo stato della sessione out-of-process di ASP.NET nel database di stato di ASP.NET SQL Server o nel servizio di stato out-of-process che viene eseguito su un computer remoto. Per ulteriori informazioni sulla protezione dello stato della sessione in un archivio di stato remoto, vedere la sezione "Stato sessione" precedentemente in questo documento.

Crittografia e verifica

Le chiavi utilizzate per crittografare e verificare i cookie di autenticazione basata su form e visualizzare lo stato devono essere le stesse attraverso tutti i server in una Web farm. Le impostazioni AutoGenerate nell'elemento <machineKey> devono essere sostituite con valori di chiave comuni.

Per ulteriori informazioni sulla generazione e la configurazione di chiavi, vedere l'articolo 312906 della Microsoft Knowledge Base "How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication" (in inglese).

DPAPI

Per crittografare i dati, a volte gli sviluppatori utilizzano DPAPI. Se si utilizza DPAPI con la chiave di computer per memorizzare i segreti, la stringa crittografata è specifica di un determinato computer e non è possibile copiare i dati crittografati attraverso computer in una Web farm o in un cluster.

Se si utilizza DPAPI con una chiave utente, è possibile decrittografare i dati in qualsiasi computer con un profilo utente comune. Tuttavia, questo non è consigliato in quando i dati possono essere decrittografati su qualsiasi computer nella rete in grado di eseguire codice mediante l'account che ha crittografato i dati.

DPAPI è idealmente adeguato per memorizzare segreti di configurazione, ad esempio, stringhe di connessione di database, che risiedono su un server Web. Vanno utilizzate altre tecniche di crittografia quando i dati crittografati sono memorizzati su un server remoto, ad esempio, in un database. Per ulteriori informazioni sulla memorizzazione di dati crittografati nel database, vedere il modulo 14 "Creazione di codice di accesso ai dati protetto."

Inizio pagina

Istantanea di un'applicazione ASP.NET protetta

La seguente istantanea mostra gli attributi di un'applicazione ASP.NET protetta e consente di confrontare rapidamente e facilmente le impostazioni con la propria configurazione.

Tabella 19.4: Istantanea di una configurazione di applicazione ASP.NET protetta

<processModel username="machine"
password="AutoGenerate" />

<processModel 
	userName="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,userName"  
	password="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,password"/>

<identity impersonate="true" 
	userName="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,userName"
	password="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,password"/>

<forms loginUrl="Restricted\login.aspx" 
	protection="All"
	requireSSL="true"      
	timeout="10"      
	name="AppNameCookie"
	path="/FormsAuth"
	slidingExpiration="true" />

   
<sessionState  mode="Off " />  

  
<machineKey validationKey="AutoGenerate,IsolateApps"            
	decryptionKey="AutoGenerate,IsolateApps"           
	validation="SHA1"/>

 
<compilation debug="false" . . .

 
<trace enabled='false' localOnly='true . . .

<customErrors mode="On"
         defaultRedirect="YourErrorPage.htm" /> 

<httpHandlers>
 <add verb="*" path="*.soap"
  	type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.rem"
	type="System.Web.HttpForbiddenHandler"/>
. . .	
</httpHandlers>

<httpHandlers>
    <add verb="*" path="*.asmx"
             type="System.Web.HttpForbiddenHandler"/>
                   . . .
</httpHandlers>

<webServices>
	<protocols>      
		<!-- <add name="HttpPost"/> -->
		<!-- <add name="HttpGet"/> -->.... 

<webServices>
 	 <protocols>
 	 		<!--<add name="Documentation"/>-->
. . .  

Inizio pagina

Riepilogo

In questo modulo è stato dimostrato come proteggere un'applicazione Web o un servizio Web ASP.NET concentrando l'attenzione sulle categorie che includono account, servizi, protocolli, file e directory, e sui dati di configurazione che vengono mantenuti nei file Machine.config e Web.config. È stato inoltre dimostrato come proteggere varie aree funzionali che dipendono dalle applicazioni Web e servizi Web ASP.NET, tra cui autenticazione, autorizzazione, stato sessione e accesso ai dati.

Per un elenco di controllo correlato, vedere "Elenco di controlo: Protezione di ASP.NET" nella sezione "Elenco di controllo" di questa guida.

Inizio pagina

Risorse aggiuntive

Per ulteriori informazioni, vedere le seguenti risorse e articoli:

Inizio pagina