Protezione delle applicazioni Web in fase di esecuzione

Articolo
10/22/2014

Aggiornamento: novembre 2007

Quando si sviluppa un'applicazione è necessario affrontare una serie di problematiche relative alla protezione. Altre problematiche e i tipici problemi che caratterizzano qualsiasi discussione sulla protezione Web riguardano la protezione dell'applicazione in fase di distribuzione ed esecuzione.

Le applicazioni Web, per definizione, consentono agli utenti di accedere a una risorsa centrale, il server Web, e attraverso di esso, ad altre risorse, come i server database. La comprensione e l'implementazione di misure di protezione adeguate consentono di raggiungere gli obiettivi illustrati di seguito:

Proteggere le risorse da accessi non autorizzati.
Limitare i livelli di accesso in base all'utente o al ruolo.
Garantire l'integrità e la riservatezza dei dati, fornendo un ambiente relativamente protetto in cui gli utenti sono in grado di utilizzare l'applicazione.
Determinare in che modo l'applicazione potrà accedere alle risorse riservate.
Assicurare che il codice venga eseguito nel modo desiderato.

In questa sezione viene illustrato a grandi linee come raggiungere tali obiettivi e vengono forniti collegamenti ad altri argomenti in cui è possibile reperire ulteriori informazioni sulle tecnologie utilizzate.

Per proteggere l'applicazione dall'accesso non autorizzato, è possibile avvalersi dei seguenti tipi di funzionalità di protezione:

Funzionalità di protezione fornite da IIS (Internet Information Services) come parte della funzione generale di server Web. Queste funzionalità includono la protezione a livello di utente, computer e file Windows.
Protezione che può essere incorporata nell'applicazione ASP.NET per fornire un accesso specifico dell'applicazione.

Processo di protezione in ASP.NET

IIS fornisce numerose opzioni di protezione per i siti Web. I meccanismi di protezione IIS sono tuttavia molto generici, poiché vengono utilizzati per tutte le applicazioni. Le opzioni di protezione IIS, ad esempio se si utilizza la protezione integrata di Windows, possono inoltre non essere sempre appropriate per l'applicazione. D'altra parte, nel caso delle applicazioni Intranet, può essere preferibile utilizzare la protezione integrata di Windows per una maggiore semplicità.

Per fornire l'accesso a porzioni specifiche dell'applicazione, è quindi possibile utilizzare la protezione ASP.NET. La protezione ASP.NET viene utilizzata in combinazione con la protezione IIS che viene estesa in modo da consentire la personalizzazione delle funzionalità, ad esempio della modalità da utilizzare per ottenere le credenziali utente.

IIS riceve le richieste dai client ed esegue i controlli di protezione stabiliti per l'applicazione utilizzando gli strumenti di gestione IIS. Se, ad esempio, l'applicazione è stata configurata in IIS per consentire l'accesso anonimo, IIS non esegue alcun controllo delle credenziali. Una volta eseguito il controllo iniziale di autenticazione, IIS invia la richiesta ad ASP.NET, che può eseguire un secondo livello di controllo. ASP.NET consente di specificare le restrizioni di accesso nell'applicazione mediante numerosi criteri per limitare l'accesso a pagine specifiche o a utenti specifici e così via.

Autenticazione

Nella tabella riportata di seguito vengono descritti i metodi di autenticazione supportati da ASP.NET, molti dei quali coincidono con quelli di IIS. Per informazioni dettagliate, vedere Autenticazione ASP.NET.

Tipo di autenticazione	Descrizione
Accesso anonimo	Per le applicazioni in cui utenti sconosciuti effettueranno richieste, in genere applicazioni Web pubbliche. Coincide con IIS.
Autenticazione di base e classificata	(Opzione di protezione IIS) In questo scenario agli utenti senza credenziali viene chiesto di fornire un nome utente e una password.
Protezione integrata di Windows (protezione NTLM)	(Opzione di protezione IIS) Se l'utente che effettua la richiesta è già stato autenticato in una rete Windows, IIS può passare le credenziali dell'utente quando viene richiesto l'accesso a una risorsa.
Autenticazione con certificati	(Opzione di protezione IIS) In questo scenario il client dispone di un certificato, ovvero di un'identificazione digitale, ottenuto da un'origine di terze parti. L'identità associata al certificato del client viene trasmessa ad ASP.NET.
Kerberos	(Opzione di protezione IIS) Il protocollo di autenticazione Kerberos definisce le interazioni tra un client e un servizio di autenticazione della rete denominato KDC (Key Distribution Center, centro distribuzione chiavi). In Windows 2000 e 2003 viene implementato un KDC come servizio di autenticazione su ciascun controller di dominio.
Autenticazione di Windows	(Opzione di protezione ASP.NET) Viene integrata con le opzioni di protezione IIS indicate in precedenza. ASP.NET accetta il token di protezione creato da IIS e lo rende disponibile come oggetto WindowsPrincipal impostato come valore della proprietà User dell'oggetto HttpContext corrente.
Autenticazione basata su form	(Opzione di protezione ASP:NET) Se è necessario autenticare un utente, ASP.NET reindirizza la richiesta alla pagina specificata. In genere questa pagina contiene un form in cui è possibile ottenere le informazioni relative al nome utente. Per una maggior protezione, è possibile scambiare il form utilizzando il protocollo HTTPS. Quando l'applicazione ottiene le informazioni del form, può eseguire un controllo specifico dell'applicazione delle credenziali dell'utente. Un aspetto importante è rappresentato dalla possibilità di controllare personalmente il processo di autenticazione, diversamente da IIS, specificando anche l'aspetto del form e la modalità da utilizzare per la memorizzazione delle informazioni sull'utente. Se un utente è stato autenticato correttamente, ASP.NET emette un cookie crittografato contenente un token con cui l'utente viene identificato per gli accessi successivi.

L'autenticazione basata su form costituisce il metodo più semplice per le applicazioni ASP.NET su Internet, poiché consente di esercitare un controllo effettivo sulla modalità di autenticazione degli utenti e di memorizzare un'autenticazione in un token nel browser.

Per ulteriori informazioni sulla protezione IIS, vedere gli argomenti relativi al controllo dell'accesso nell'area tecnica di Windows Server per IIS sul sito Web Microsoft TechNet. Per ulteriori informazioni sull'autenticazione ASP.NET, vedere Autenticazione ASP.NET.

Per ulteriori informazioni sull'utilizzo dell'autenticazione basata su form con transizione di protocollo e delega vincolata in un ambiente di dominio Windows Server 2003, vedere il documento relativo transizione di protocolli e alla delega vincolata in Kerberos.

Autorizzazione

Quando viene eseguita, l'applicazione Web richiederà risorse al server Web e, spesso, anche ad altri processi, ad esempio a un database. Il processo ASP.NET viene eseguito in un contesto utente che determina il modo in cui l'applicazione richiederà tali risorse. Il processo ASP.NET viene eseguito come un utente locale speciale denominato ASPNET (per impostazione predefinita) in Windows 2000 e Windows XP Professional Edition o come identità del pool di applicazioni per l'applicazione ASP.NET in Windows 2003 (per impostazione predefinita, l'account NETWORK SERVICE locale). Questi account vengono eseguiti con autorizzazioni limitate. È possibile specificare un contesto utente diverso per il processo ASP.NET, tra cui l'account SYSTEM locale (che consente di eseguire l'applicazione nel contesto di amministratore) o un utente con credenziali fornite in modo esplicito, sebbene questa opzione non sia consigliabile.

Nell'applicazione ASP.NET è possibile definire per utenti diversi un accesso autorizzato a diverse risorse. Se nell'applicazione viene utilizzata l'autenticazione di Windows, è possibile utilizzare le autorizzazioni Windows per determinare l'autorizzazione per accedere a cartelle o file specifici sul server.

In alternativa, è possibile utilizzare l'autorizzazione basata su URL, che consente di concedere o negare l'autorizzazione in base a diversi criteri:

Specifici utenti o identità, in base alle credenziali fornite dall'utente.
Ruoli, ovvero entità definite per consentire a più utenti di condividere privilegi in base a una funzione o a un ruolo comune.
Verbi, ovvero i processi HTTP, quali GET e POST, per l'accesso a parti dell'applicazione.

È possibile, ad esempio, specificare che tutti gli utenti possono ottenere pagine dall'applicazione, eseguendo il verbo GET, ma che solo specifici utenti possono inserirvi pagine. Analogamente, è possibile consentire a tutti gli utenti di ottenere pagine e negare il diritto di inserire pagine solo a ruoli specifici.

È possibile concedere l'autorizzazione basata su URL per l'intera applicazione o solo per determinate directory. Un tipico utilizzo consiste nel consentire a tutti gli utenti di visualizzare le pagine in una directory pubblica e conservare le pagine con accesso limitato in una directory diversa che può essere utilizzata solo da parte di utenti o ruoli specifici.

Nota:
Per impostazione predefinita, i file statici, quali le immagini e i fogli di stile, non sono soggetti all'autorizzazione ASP.NET quando vengono forniti tramite IIS. È possibile utilizzare le funzioni di protezione IIS per limitare l'accesso ai file statici se non si desidera che tutti gli utenti siano in grado di accedere ai file. Se si utilizza ASP.NET Development Server per eseguire il test dell'applicazione ASP.NET, si noterà un comportamento diverso poiché i file statici sono soggetti all'autorizzazione ASP.NET e non verranno forniti a un utente anonimo quando l'accesso anonimo a tali file è disattivato. In alternativa, è possibile associare le estensioni dei file statici in IIS all'estensione ISAPI ASP.NET affinché vengano applicate le regole di autorizzazione di ASP.NET.

Per impostazione predefinita, i file statici, quali le immagini e i fogli di stile, non sono soggetti all'autorizzazione ASP.NET quando vengono forniti tramite IIS. È possibile utilizzare le funzioni di protezione IIS per limitare l'accesso ai file statici se non si desidera che tutti gli utenti siano in grado di accedere ai file. Se si utilizza ASP.NET Development Server per eseguire il test dell'applicazione ASP.NET, si noterà un comportamento diverso poiché i file statici sono soggetti all'autorizzazione ASP.NET e non verranno forniti a un utente anonimo quando l'accesso anonimo a tali file è disattivato. In alternativa, è possibile associare le estensioni dei file statici in IIS all'estensione ISAPI ASP.NET affinché vengano applicate le regole di autorizzazione di ASP.NET.

Per ulteriori informazioni, vedere Autorizzazione ASP.NET e Suggerimenti di base sulla protezione delle applicazioni Web.

File di configurazione ASP.NET

Le opzioni di protezione ASP.NET vengono stabilite utilizzando le impostazioni in un file Web.config. In questo file è possibile includere elementi predefiniti per diverse opzioni di protezione, incluse sezioni per l'autenticazione e l'autorizzazione. Le sezioni importanti del file Web.config possono essere simili a quelle riportate di seguito.

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

L'applicazione può contenere più file di configurazione. Per impostazione predefinita, nella radice dell'applicazione è presente un file di configurazione che specifica la protezione per l'intera applicazione. Le impostazioni di protezione vengono pertanto ereditate dalle sottocartelle. Tuttavia, è anche possibile creare file di configurazione in singole cartelle per creare impostazioni di protezione specifiche per tali cartelle.

Per ulteriori informazioni, vedere Architettura ASP.NET.

Protezione dei servizi Web XML

I servizi Web XML che utilizzano file ASMX vengono eseguiti come applicazioni Web che utilizzano ASP.NET e pertanto partecipano allo stesso modello di protezione come qualsiasi applicazione ASP.NET. Un servizio Web XML, ad esempio, può essere configurato in modo che utilizzi l'autenticazione di base o la protezione integrata di Windows.

In fase di progettazione, quando si tenta di aggiungere un riferimento a un servizio Web XML, ovvero quando si richiedono i documenti di individuazione del servizio Web XML, il servizio Web XML esegue l'autenticazione standard dell'applicazione Web in base alla modalità di configurazione utilizzata. Se il servizio Web XML, ad esempio, è configurato in modo che utilizzi l'autenticazione di base, il servizio attenderà di ricevere un nome utente e una password dal client che effettua la richiesta. Se il servizio Web XML utilizza l'autenticazione di base, ad esempio, nella finestra di dialogo Aggiungi riferimento Web verrà chiesto di fornire le credenziali.

Se si compila un'applicazione che include chiamate a un servizio Web XML, è necessario assicurarsi di disporre delle credenziali appropriate prima di effettuare la chiamata, altrimenti la chiamata avrà esito negativo. In fase di esecuzione è possibile passare le credenziali al servizio Web XML impostando la proprietà Credentials dell'oggetto lato client che rappresenta il servizio Web XML prima di chiamarne i metodi.

Poiché altre opzioni di protezione ASP.NET potrebbero non essere sufficientemente flessibili, i servizi Web XML consentono di implementare una soluzione di autenticazione personalizzata in cui le informazioni sulle credenziali vengono passate all'interno di intestazioni SOAP. In questa soluzione, le credenziali vengono passate in una parte facoltativa del messaggio scambiato tra client e server. È quindi possibile scrivere un modulo HTTP personalizzato (implementando l'interfaccia IHttpModule) che può attendere le informazioni contenute nell'intestazione e chiamare il codice di autenticazione personale.

Come con altre applicazioni ASP.NET, il servizio Web XML può implementare autorizzazioni specifiche basate su ruoli per limitare l'accesso a parti specifiche dell'applicazione.

Per ulteriori informazioni, vedere Infrastruttura dei servizi Web XML e Protezione dei servizi Web XML creati mediante ASP.NET.

Definizione di integrità e riservatezza dei dati

L'autenticazione e l'autorizzazione definiscono l'identità degli utenti e le risorse alle quali è possibile accedere. Queste funzionalità di protezione sono progettate principalmente per proteggere l'applicazione Web da un uso non autorizzato.

Tuttavia, un altro aspetto importante della protezione è rappresentato dalla possibilità di proteggere le informazioni dell'utente e garantire la sicurezza necessaria per lo scambio di informazioni riservate. Se, ad esempio, l'applicazione chiede all'utente di specificare il numero di conto corrente o di carta di credito, informazioni personali o qualsiasi altra informazione che gli utenti non desiderano rendere pubblica, è necessario fornire un modo per inoltrare queste informazioni in modo protetto.

Per lo scambio di informazioni mediante il protocollo HTTPS, è possibile utilizzare il protocollo SSL (Secure Socket Layer) in IIS. SSL fornisce la crittografia in entrambe le direzioni: le informazioni vengono trasmesse all'utente utilizzando la crittografia e, analogamente, vengono crittografate anche le informazioni che l'utente invia all'applicazione.

Definizione di SSL e crittografia

Per utilizzare la crittografia e SSL, è necessario ottenere un'identità o un certificato server per la società. Il certificato è costituito da una firma digitale che identifica il sito in modo da impedirne la rappresentazione. Per le applicazioni Internet (pubbliche),il certificato server viene rilasciato da un'autorità di certificazione autorizzata. Per le applicazioni Intranet (private), è possibile emettere un certificato server in modo autonomo. Questo certificato consente di proteggere un'applicazione interna, ad esempio, un sito del personale.

Il certificato server consente inoltre di impostare connessioni crittografate mediante SSL con gli utenti del browser. SSL utilizza un metodo di crittografia denominato crittografia a chiave pubblica. In questa forma di crittografia vengono utilizzate due chiavi: una chiave pubblica, utilizzata per crittografare i dati, e una chiave privata, da tenere segreta, utilizzata per decrittografare le informazioni crittografate con la chiave pubblica. Il certificato server ottenuto include una chiave pubblica. Quando gli utenti desiderano utilizzare SSL, l'applicazione invia il certificato e la chiave pubblica al browser. Il browser e il server utilizzano quindi la chiave pubblica per definire un modo per crittografare lo scambio delle informazioni.

Nota:
L'utilizzo di SSL richiede che il browser supporti una chiave di crittografia lunga almeno 40 bit. Questo livello è disponibile nella maggior parte dei browser. Tale lunghezza di chiave non è tuttavia considerata sicura. È anche possibile configurare l'applicazione in IIS in modo che consenta solo connessioni SSL con chiave a 128 bit.

Una volta ottenuto un certificato server, è possibile indicare agli utenti di utilizzare SSL utilizzando https:// come prefisso per ottenere e inviare pagine Web. Il sito Web può inoltre essere configurato in IIS in modo che accetti solo connessioni HTTPS. IIS e il browser utilizzeranno automaticamente un canale crittografato per lo scambio di informazioni.

Per ulteriori informazioni sull'utilizzo di SSL, vedere l'articolo Q307267, "How to: Secure XML Web Services with Secure Sockets Layer in Windows 2000" in Microsoft Knowledge Base (informazioni in lingua inglese). Per informazioni sulla crittografia, vedere Cenni preliminari sulla crittografia. Per informazioni sui certificati e sulla configurazione di SSL, vedere l'area tecnica di Windows Server per IIS sul sito Web Microsoft TechNet.

Utilizzo della protezione del codice .NET

Come altro aspetto importante della protezione, è necessario adottare delle misure per garantire che il codice utilizzato nell'applicazione sia protetto da un utilizzo non corretto, sia in caso di esecuzione involontaria in un contesto non adatto, sia in caso di impiego intenzionalmente errato. Poiché ASP.NET fa parte di .NET Framework, è possibile usufruire della sicurezza per l'accesso al codice per definire le autorizzazioni da concedere al codice. Per ulteriori informazioni, vedere Sicurezza per l'accesso al codice.

Vedere anche

Concetti

Suggerimenti di base sulla protezione delle applicazioni Web

Condividi tramite